From Newsgroup: comp.theory

https://github.com/plolcott/x86utm/blob/master/Halt7.c https://github.com/plolcott/x86utm/blob/master/README.md

*Succinct proof that the Halting Problem Theorem is incorrect*

Axiom 1 --- Paraphrase of Emil Post
All computations are essentially the application of finite string transformation rules to finite string inputs to derive any and all
outputs. All computations are only allowed to apply finite string transformations to their finite string inputs.

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

Axiom 3
This is a single unique sequence thus making every other sequence incorrect.

Axiom 4
This sequence does not derive the behavior of DD() executed from main().
HHH cannot report on the behavior of its caller DD().

Axiom 5
DD correctly simulated by HHH cannot possibly reach its simulated
final halt state is determined by the execution trace shown below.

Conclusion
Simulating halt decider HHH is applied to the conventional
Halting Problem proof counter-example finite string input DD.
HHH applies Emil Post finite string transformations to this DD.
Because the input is C source code correct transformations must
correspond to the operational semantics of the C programming
language. The above prohibits HHH from reporting on the behavior
of its caller DD() directly executed in main(). This also enables
HHH to correctly reject its input finite string DD as non-halting.

typedef int (*ptr)();
int HHH(ptr P);

01 int DD()
02 {
03 int Halt_Status = HHH(DD);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 void main()
10 {
11 HHH(DD);
12 }

Correct simulation is defined as DD simulated by HHH according to the (operational) semantics of the C programming language. Ordinary software engineering conclusively proves that DD correctly simulated by HHH
cannot possibly reach its own simulated return instruction and terminate normally.

Execution Trace
Line 11: main() invokes HHH(DD);

keeps repeating (unless aborted)
Line 03: simulated DD() invokes simulated HHH(DD) that simulates DD()

Simulation invariant
DD correctly simulated by HHH cannot possibly reach past its own line 03 whether or not HHH ever aborts this simulation.

DD correctly simulated by HHH cannot possibly reach its simulated final
state.
--
Copyright 2026 Olcott

The essence of computation is applying finite
string transformations to finite string inputs
to derive outputs. // paraphrase of Emil Post

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

From Newsgroup: comp.theory

On 10/10/26 1:17 PM, olcott wrote:

https://github.com/plolcott/x86utm/blob/master/Halt7.c https://github.com/plolcott/x86utm/blob/master/README.md

*Succinct proof that the Halting Problem Theorem is incorrect*

Axiom 1 --- Paraphrase of Emil Post
All computations are essentially the application of finite string transformation rules to finite string inputs to derive any and all
outputs. All computations are only allowed to apply finite string transformations to their finite string inputs.

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

Axiom 3
This is a single unique sequence thus making every other sequence
incorrect.

Axiom 4
This sequence does not derive the behavior of DD() executed from main().
HHH cannot report on the behavior of its caller DD().

Axiom 5
DD correctly simulated by HHH cannot possibly reach its simulated
final halt state is determined by the execution trace shown below.

Conclusion
Simulating halt decider HHH is applied to the conventional
Halting Problem proof counter-example finite string input DD.
HHH applies Emil Post finite string transformations to this DD.
Because the input is C source code correct transformations must
correspond to the operational semantics of the C programming
language. The above prohibits HHH from reporting on the behavior
of its caller DD() directly executed in main(). This also enables
HHH to correctly reject its input finite string DD as non-halting.

typedef int (*ptr)();
int HHH(ptr P);

01 int DD()
02 {
03   int Halt_Status = HHH(DD);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }
08
09 void main()
10 {
11  HHH(DD);
12 }

Correct simulation is defined as DD simulated by HHH according to the (operational) semantics of the C programming language. Ordinary software engineering conclusively proves that DD correctly simulated by HHH
cannot possibly reach its own simulated return instruction and terminate normally.

Execution Trace
Line 11: main() invokes HHH(DD);

keeps repeating (unless aborted)
Line 03: simulated DD() invokes simulated HHH(DD) that simulates DD()

Simulation invariant
DD correctly simulated by HHH cannot possibly reach past its own line 03 whether or not HHH ever aborts this simulation.

DD correctly simulated by HHH cannot possibly reach its simulated final state.

bruh ur never gunna build a machine that decides whether any given input machine halts or not

the problem of constructing paradoxical dependencies that is inherent to computing prevents this

whatever innovation is to had on the matter is going to be in-spite of
that limitation, not by denying or removing it
--
arising us out of the computing dark ages,
please excuse my pseudo-pyscript,
~ the lil crank that could

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/10/2026 3:52 PM, dart200 wrote:

On 10/10/26 1:17 PM, olcott wrote:

https://github.com/plolcott/x86utm/blob/master/Halt7.c
https://github.com/plolcott/x86utm/blob/master/README.md

*Succinct proof that the Halting Problem Theorem is incorrect*

Axiom 1 --- Paraphrase of Emil Post
All computations are essentially the application of finite string
transformation rules to finite string inputs to derive any and all
outputs. All computations are only allowed to apply finite string
transformations to their finite string inputs.

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

Axiom 3
This is a single unique sequence thus making every other sequence
incorrect.

Axiom 4
This sequence does not derive the behavior of DD() executed from main().
HHH cannot report on the behavior of its caller DD().

Axiom 5
DD correctly simulated by HHH cannot possibly reach its simulated
final halt state is determined by the execution trace shown below.

Conclusion
Simulating halt decider HHH is applied to the conventional
Halting Problem proof counter-example finite string input DD.
HHH applies Emil Post finite string transformations to this DD.
Because the input is C source code correct transformations must
correspond to the operational semantics of the C programming
language. The above prohibits HHH from reporting on the behavior
of its caller DD() directly executed in main(). This also enables
HHH to correctly reject its input finite string DD as non-halting.

typedef int (*ptr)();
int HHH(ptr P);

01 int DD()
02 {
03   int Halt_Status = HHH(DD);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }
08
09 void main()
10 {
11  HHH(DD);
12 }

Correct simulation is defined as DD simulated by HHH according to the
(operational) semantics of the C programming language. Ordinary
software engineering conclusively proves that DD correctly simulated
by HHH cannot possibly reach its own simulated return instruction and
terminate normally.

Execution Trace
Line 11: main() invokes HHH(DD);

keeps repeating (unless aborted)
Line 03: simulated DD() invokes simulated HHH(DD) that simulates DD()

Simulation invariant
DD correctly simulated by HHH cannot possibly reach past its own line
03 whether or not HHH ever aborts this simulation.

DD correctly simulated by HHH cannot possibly reach its simulated
final state.

bruh ur never gunna build a machine that decides whether any given input machine halts or not

You did not carefully study the above words that
took me 20,000 hours over 22 years to write.

If you spent 1 / 40,000th of the time that I did
to carefully studying my words you would see how
terrible your paraphrase is.

the problem of constructing paradoxical dependencies that is inherent to computing prevents this

whatever innovation is to had on the matter is going to be in-spite of
that limitation, not by denying or removing it

--
Copyright 2026 Olcott

The essence of computation is applying finite
string transformations to finite string inputs
to derive outputs. // paraphrase of Emil Post

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

From Newsgroup: comp.theory

On 10/10/26 2:24 PM, olcott wrote:

On 10/10/2026 3:52 PM, dart200 wrote:

On 10/10/26 1:17 PM, olcott wrote:

https://github.com/plolcott/x86utm/blob/master/Halt7.c
https://github.com/plolcott/x86utm/blob/master/README.md

*Succinct proof that the Halting Problem Theorem is incorrect*

Axiom 1 --- Paraphrase of Emil Post
All computations are essentially the application of finite string
transformation rules to finite string inputs to derive any and all
outputs. All computations are only allowed to apply finite string
transformations to their finite string inputs.

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

Axiom 3
This is a single unique sequence thus making every other sequence
incorrect.

Axiom 4
This sequence does not derive the behavior of DD() executed from main(). >>> HHH cannot report on the behavior of its caller DD().

Axiom 5
DD correctly simulated by HHH cannot possibly reach its simulated
final halt state is determined by the execution trace shown below.

Conclusion
Simulating halt decider HHH is applied to the conventional
Halting Problem proof counter-example finite string input DD.
HHH applies Emil Post finite string transformations to this DD.
Because the input is C source code correct transformations must
correspond to the operational semantics of the C programming
language. The above prohibits HHH from reporting on the behavior
of its caller DD() directly executed in main(). This also enables
HHH to correctly reject its input finite string DD as non-halting.

typedef int (*ptr)();
int HHH(ptr P);

01 int DD()
02 {
03   int Halt_Status = HHH(DD);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }
08
09 void main()
10 {
11  HHH(DD);
12 }

Correct simulation is defined as DD simulated by HHH according to the
(operational) semantics of the C programming language. Ordinary
software engineering conclusively proves that DD correctly simulated
by HHH cannot possibly reach its own simulated return instruction and
terminate normally.

Execution Trace
Line 11: main() invokes HHH(DD);

keeps repeating (unless aborted)
Line 03: simulated DD() invokes simulated HHH(DD) that simulates DD()

Simulation invariant
DD correctly simulated by HHH cannot possibly reach past its own line
03 whether or not HHH ever aborts this simulation.

DD correctly simulated by HHH cannot possibly reach its simulated
final state.

bruh ur never gunna build a machine that decides whether any given
input machine halts or not

You did not carefully study the above words that
took me 20,000 hours over 22 years to write.

If you spent 1 / 40,000th of the time that I did
to carefully studying my words you would see how
terrible your paraphrase is.

bragging about time spent ain't a good look dud, no correlation between
time spent and correctness, as unfortunate as that is

HHH(DD)->0 still does not accurately describe the behavior of DD... i'm
almost positive allowing such a thing would allow for a proof that 1=0 somewhere, and at that point we've lost all consistency in reason

u can't use runtime inf recursion detection to get around the
undecidability of the halting problem, no matter how many times u repeat
the same thing, or hide it beneath increasingly more proof-like phrasing

the problem of constructing paradoxical dependencies that is inherent
to computing prevents this

whatever innovation is to had on the matter is going to be in-spite of
that limitation, not by denying or removing it

--
arising us out of the computing dark ages,
please excuse my pseudo-pyscript,
~ the lil crank that could
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/10/2026 7:53 PM, dart200 wrote:

On 10/10/26 2:24 PM, olcott wrote:

On 10/10/2026 3:52 PM, dart200 wrote:

On 10/10/26 1:17 PM, olcott wrote:

https://github.com/plolcott/x86utm/blob/master/Halt7.c
https://github.com/plolcott/x86utm/blob/master/README.md

*Succinct proof that the Halting Problem Theorem is incorrect*

Axiom 1 --- Paraphrase of Emil Post
All computations are essentially the application of finite string
transformation rules to finite string inputs to derive any and all
outputs. All computations are only allowed to apply finite string
transformations to their finite string inputs.

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

Axiom 3
This is a single unique sequence thus making every other sequence
incorrect.

Axiom 4
This sequence does not derive the behavior of DD() executed from
main().
HHH cannot report on the behavior of its caller DD().

Axiom 5
DD correctly simulated by HHH cannot possibly reach its simulated
final halt state is determined by the execution trace shown below.

Conclusion
Simulating halt decider HHH is applied to the conventional
Halting Problem proof counter-example finite string input DD.
HHH applies Emil Post finite string transformations to this DD.
Because the input is C source code correct transformations must
correspond to the operational semantics of the C programming
language. The above prohibits HHH from reporting on the behavior
of its caller DD() directly executed in main(). This also enables
HHH to correctly reject its input finite string DD as non-halting.

typedef int (*ptr)();
int HHH(ptr P);

01 int DD()
02 {
03   int Halt_Status = HHH(DD);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }
08
09 void main()
10 {
11  HHH(DD);
12 }

Correct simulation is defined as DD simulated by HHH according to
the (operational) semantics of the C programming language. Ordinary
software engineering conclusively proves that DD correctly simulated
by HHH cannot possibly reach its own simulated return instruction
and terminate normally.

Execution Trace
Line 11: main() invokes HHH(DD);

keeps repeating (unless aborted)
Line 03: simulated DD() invokes simulated HHH(DD) that simulates DD()

Simulation invariant
DD correctly simulated by HHH cannot possibly reach past its own
line 03 whether or not HHH ever aborts this simulation.

DD correctly simulated by HHH cannot possibly reach its simulated
final state.

bruh ur never gunna build a machine that decides whether any given
input machine halts or not

You did not carefully study the above words that
took me 20,000 hours over 22 years to write.

If you spent 1 / 40,000th of the time that I did
to carefully studying my words you would see how
terrible your paraphrase is.

bragging about time spent ain't a good look dud, no correlation between
time spent and correctness, as unfortunate as that is

HHH(DD)->0 still does not accurately describe the behavior of DD...

Spent 30 minutes reading and re-reading this (2.5 pages) https://github.com/plolcott/x86utm/blob/master/README.md
before any of your replies will have any actual basis.

i'm
almost positive allowing such a thing would allow for a proof that 1=0 somewhere, and at that point we've lost all consistency in reason

It is true that no halt decider can possibly return a halt
status TO ITS CALLER that does the opposite of whatever
it returns. It is also true that NO HALT DECIDER IS EVER
ACCOUNTABLE FOR THE BEHAVIOR OF ITS OWN CALLER.

u can't use runtime inf recursion detection to get around the
undecidability of the halting problem, no matter how many times u repeat
the same thing, or hide it beneath increasingly more proof-like phrasing

the problem of constructing paradoxical dependencies that is inherent
to computing prevents this

whatever innovation is to had on the matter is going to be in-spite
of that limitation, not by denying or removing it

--
Copyright 2026 Olcott

The essence of computation is applying finite
string transformations to finite string inputs
to derive outputs. // paraphrase of Emil Post

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

From Newsgroup: comp.theory

On 10/10/26 6:02 PM, olcott wrote:

On 10/10/2026 7:53 PM, dart200 wrote:

On 10/10/26 2:24 PM, olcott wrote:

On 10/10/2026 3:52 PM, dart200 wrote:

On 10/10/26 1:17 PM, olcott wrote:

https://github.com/plolcott/x86utm/blob/master/Halt7.c
https://github.com/plolcott/x86utm/blob/master/README.md

*Succinct proof that the Halting Problem Theorem is incorrect*

Axiom 1 --- Paraphrase of Emil Post
All computations are essentially the application of finite string
transformation rules to finite string inputs to derive any and all
outputs. All computations are only allowed to apply finite string
transformations to their finite string inputs.

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

Axiom 3
This is a single unique sequence thus making every other sequence
incorrect.

Axiom 4
This sequence does not derive the behavior of DD() executed from
main().
HHH cannot report on the behavior of its caller DD().

Axiom 5
DD correctly simulated by HHH cannot possibly reach its simulated
final halt state is determined by the execution trace shown below.

Conclusion
Simulating halt decider HHH is applied to the conventional
Halting Problem proof counter-example finite string input DD.
HHH applies Emil Post finite string transformations to this DD.
Because the input is C source code correct transformations must
correspond to the operational semantics of the C programming
language. The above prohibits HHH from reporting on the behavior
of its caller DD() directly executed in main(). This also enables
HHH to correctly reject its input finite string DD as non-halting.

typedef int (*ptr)();
int HHH(ptr P);

01 int DD()
02 {
03   int Halt_Status = HHH(DD);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }
08
09 void main()
10 {
11  HHH(DD);
12 }

Correct simulation is defined as DD simulated by HHH according to
the (operational) semantics of the C programming language. Ordinary >>>>> software engineering conclusively proves that DD correctly
simulated by HHH cannot possibly reach its own simulated return
instruction and terminate normally.

Execution Trace
Line 11: main() invokes HHH(DD);

keeps repeating (unless aborted)
Line 03: simulated DD() invokes simulated HHH(DD) that simulates DD() >>>>>
Simulation invariant
DD correctly simulated by HHH cannot possibly reach past its own
line 03 whether or not HHH ever aborts this simulation.

DD correctly simulated by HHH cannot possibly reach its simulated
final state.

bruh ur never gunna build a machine that decides whether any given
input machine halts or not

You did not carefully study the above words that
took me 20,000 hours over 22 years to write.

If you spent 1 / 40,000th of the time that I did
to carefully studying my words you would see how
terrible your paraphrase is.

bragging about time spent ain't a good look dud, no correlation
between time spent and correctness, as unfortunate as that is

HHH(DD)->0 still does not accurately describe the behavior of DD...

Spent 30 minutes reading and re-reading this (2.5 pages) https://github.com/plolcott/x86utm/blob/master/README.md
before any of your replies will have any actual basis.

ur like trying to deny that water is wet dud

DD is a halting function, no??? HHH(DD)->0 does not indicate that DD is
a halting function, so it doesn't match to DDs true behavior. u haven't properly justified why that ought to be

i'm almost positive allowing such a thing would allow for a proof that
1=0 somewhere, and at that point we've lost all consistency in reason

It is true that no halt decider can possibly return a halt
status TO ITS CALLER that does the opposite of whatever
it returns. It is also true that NO HALT DECIDER IS EVER
ACCOUNTABLE FOR THE BEHAVIOR OF ITS OWN CALLER.

nah i don't buy that excuse. u need to be able to precisely define the
sets of machines which it decides on vs that which it doesn't, and u
haven't done that. i think what's got u all worked up is u seem to have produced what is technically a total decider, in that it has some
definite return for all input machines ... but it's certainly _not_ a
total halting decider as demonstrated bc of ur example.

i'm working on a specification for an effectively total halting
classifier that captures all machines we're interested in, but not
technically a total halting decider. i've called it a partial halting recognizer, and i'm trying to specifically justify the logic on where it
does and does not manage to recognize a halting input machine, and more importantly why we can accept when it does not recognize all input machines:

𝓱p = (m: machine) -> {
true: if m halts and not depends on any n where 𝓱p(n)->false
false: otherwise
}

u can't use runtime inf recursion detection to get around the
undecidability of the halting problem, no matter how many times u
repeat the same thing, or hide it beneath increasingly more proof-like
phrasing

the problem of constructing paradoxical dependencies that is
inherent to computing prevents this

whatever innovation is to had on the matter is going to be in-spite
of that limitation, not by denying or removing it

--
arising us out of the computing dark ages,
please excuse my pseudo-pyscript,
~ the lil crank that could
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/10/2026 10:40 PM, dart200 wrote:

On 10/10/26 6:02 PM, olcott wrote:

On 10/10/2026 7:53 PM, dart200 wrote:

On 10/10/26 2:24 PM, olcott wrote:

On 10/10/2026 3:52 PM, dart200 wrote:

On 10/10/26 1:17 PM, olcott wrote:

https://github.com/plolcott/x86utm/blob/master/Halt7.c
https://github.com/plolcott/x86utm/blob/master/README.md

*Succinct proof that the Halting Problem Theorem is incorrect*

Axiom 1 --- Paraphrase of Emil Post
All computations are essentially the application of finite string
transformation rules to finite string inputs to derive any and all >>>>>> outputs. All computations are only allowed to apply finite string
transformations to their finite string inputs.

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

Axiom 3
This is a single unique sequence thus making every other sequence >>>>>> incorrect.

Axiom 4
This sequence does not derive the behavior of DD() executed from
main().
HHH cannot report on the behavior of its caller DD().

Axiom 5
DD correctly simulated by HHH cannot possibly reach its simulated
final halt state is determined by the execution trace shown below. >>>>>>
Conclusion
Simulating halt decider HHH is applied to the conventional
Halting Problem proof counter-example finite string input DD.
HHH applies Emil Post finite string transformations to this DD.
Because the input is C source code correct transformations must
correspond to the operational semantics of the C programming
language. The above prohibits HHH from reporting on the behavior
of its caller DD() directly executed in main(). This also enables
HHH to correctly reject its input finite string DD as non-halting. >>>>>>
typedef int (*ptr)();
int HHH(ptr P);

01 int DD()
02 {
03   int Halt_Status = HHH(DD);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }
08
09 void main()
10 {
11  HHH(DD);
12 }

Correct simulation is defined as DD simulated by HHH according to >>>>>> the (operational) semantics of the C programming language.
Ordinary software engineering conclusively proves that DD
correctly simulated by HHH cannot possibly reach its own simulated >>>>>> return instruction and terminate normally.

Execution Trace
Line 11: main() invokes HHH(DD);

keeps repeating (unless aborted)
Line 03: simulated DD() invokes simulated HHH(DD) that simulates DD() >>>>>>
Simulation invariant
DD correctly simulated by HHH cannot possibly reach past its own
line 03 whether or not HHH ever aborts this simulation.

DD correctly simulated by HHH cannot possibly reach its simulated >>>>>> final state.

bruh ur never gunna build a machine that decides whether any given
input machine halts or not

You did not carefully study the above words that
took me 20,000 hours over 22 years to write.

If you spent 1 / 40,000th of the time that I did
to carefully studying my words you would see how
terrible your paraphrase is.

bragging about time spent ain't a good look dud, no correlation
between time spent and correctness, as unfortunate as that is

HHH(DD)->0 still does not accurately describe the behavior of DD...

Spent 30 minutes reading and re-reading this (2.5 pages)
https://github.com/plolcott/x86utm/blob/master/README.md
before any of your replies will have any actual basis.

ur like trying to deny that water is wet dud

DD is a halting function, no??? HHH(DD)->0 does not indicate that DD is
a halting function, so it doesn't match to DDs true behavior. u haven't properly justified why that ought to be

i'm almost positive allowing such a thing would allow for a proof
that 1=0 somewhere, and at that point we've lost all consistency in
reason

It is true that no halt decider can possibly return a halt
status TO ITS CALLER that does the opposite of whatever
it returns. It is also true that NO HALT DECIDER IS EVER
ACCOUNTABLE FOR THE BEHAVIOR OF ITS OWN CALLER.

nah i don't buy that excuse. u need to be able to precisely define the
sets of machines

The set of machines that it decides have always been zero.
It only decides the halting property of finite strings.

which it decides on vs that which it doesn't, and u
haven't done that. i think what's got u all worked up is u seem to have produced what is technically a total decider, in that it has some
definite return for all input machines ... but it's certainly _not_ a
total halting decider as demonstrated bc of ur example.

i'm working on a specification for an effectively total halting
classifier that captures all machines we're interested in, but not technically a total halting decider. i've called it a partial halting recognizer, and i'm trying to specifically justify the logic on where it does and does not manage to recognize a halting input machine, and more importantly why we can accept when it does not recognize all input
machines:

I have done more than that.

  𝓱p = (m: machine) -> {
    true: if m halts and not depends on any n where 𝓱p(n)->false
    false: otherwise
  }

u can't use runtime inf recursion detection to get around the
undecidability of the halting problem, no matter how many times u
repeat the same thing, or hide it beneath increasingly more proof-
like phrasing

the problem of constructing paradoxical dependencies that is
inherent to computing prevents this

whatever innovation is to had on the matter is going to be in-spite >>>>> of that limitation, not by denying or removing it

--
Copyright 2026 Olcott

The essence of computation is applying finite
string transformations to finite string inputs
to derive outputs. // paraphrase of Emil Post

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

From Newsgroup: comp.theory

On 10/11/26 5:46 AM, olcott wrote:

On 10/10/2026 10:40 PM, dart200 wrote:

On 10/10/26 6:02 PM, olcott wrote:

On 10/10/2026 7:53 PM, dart200 wrote:

On 10/10/26 2:24 PM, olcott wrote:

On 10/10/2026 3:52 PM, dart200 wrote:

On 10/10/26 1:17 PM, olcott wrote:

https://github.com/plolcott/x86utm/blob/master/Halt7.c
https://github.com/plolcott/x86utm/blob/master/README.md

*Succinct proof that the Halting Problem Theorem is incorrect*

Axiom 1 --- Paraphrase of Emil Post
All computations are essentially the application of finite string >>>>>>> transformation rules to finite string inputs to derive any and all >>>>>>> outputs. All computations are only allowed to apply finite string >>>>>>> transformations to their finite string inputs.

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

Axiom 3
This is a single unique sequence thus making every other sequence >>>>>>> incorrect.

Axiom 4
This sequence does not derive the behavior of DD() executed from >>>>>>> main().
HHH cannot report on the behavior of its caller DD().

Axiom 5
DD correctly simulated by HHH cannot possibly reach its simulated >>>>>>> final halt state is determined by the execution trace shown below. >>>>>>>
Conclusion
Simulating halt decider HHH is applied to the conventional
Halting Problem proof counter-example finite string input DD.
HHH applies Emil Post finite string transformations to this DD.
Because the input is C source code correct transformations must
correspond to the operational semantics of the C programming
language. The above prohibits HHH from reporting on the behavior >>>>>>> of its caller DD() directly executed in main(). This also enables >>>>>>> HHH to correctly reject its input finite string DD as non-halting. >>>>>>>
typedef int (*ptr)();
int HHH(ptr P);

01 int DD()
02 {
03   int Halt_Status = HHH(DD);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }
08
09 void main()
10 {
11  HHH(DD);
12 }

Correct simulation is defined as DD simulated by HHH according to >>>>>>> the (operational) semantics of the C programming language.
Ordinary software engineering conclusively proves that DD
correctly simulated by HHH cannot possibly reach its own
simulated return instruction and terminate normally.

Execution Trace
Line 11: main() invokes HHH(DD);

keeps repeating (unless aborted)
Line 03: simulated DD() invokes simulated HHH(DD) that simulates >>>>>>> DD()

Simulation invariant
DD correctly simulated by HHH cannot possibly reach past its own >>>>>>> line 03 whether or not HHH ever aborts this simulation.

DD correctly simulated by HHH cannot possibly reach its simulated >>>>>>> final state.

bruh ur never gunna build a machine that decides whether any given >>>>>> input machine halts or not

You did not carefully study the above words that
took me 20,000 hours over 22 years to write.

If you spent 1 / 40,000th of the time that I did
to carefully studying my words you would see how
terrible your paraphrase is.

bragging about time spent ain't a good look dud, no correlation
between time spent and correctness, as unfortunate as that is

HHH(DD)->0 still does not accurately describe the behavior of DD...

Spent 30 minutes reading and re-reading this (2.5 pages)
https://github.com/plolcott/x86utm/blob/master/README.md
before any of your replies will have any actual basis.

ur like trying to deny that water is wet dud

DD is a halting function, no??? HHH(DD)->0 does not indicate that DD
is a halting function, so it doesn't match to DDs true behavior. u
haven't properly justified why that ought to be

i'm almost positive allowing such a thing would allow for a proof
that 1=0 somewhere, and at that point we've lost all consistency in
reason

It is true that no halt decider can possibly return a halt
status TO ITS CALLER that does the opposite of whatever
it returns. It is also true that NO HALT DECIDER IS EVER
ACCOUNTABLE FOR THE BEHAVIOR OF ITS OWN CALLER.

nah i don't buy that excuse. u need to be able to precisely define the
sets of machines

The set of machines that it decides have always been zero.
It only decides the halting property of finite strings.

it decides some property that you haven't fully specified. it does not compute/decide the objective total halting map from input machine
represented by a finite string to the halting property dud

𝓱 = (m: machine) -> {
true: if m halts
false: otherwise
}

i can't build that either. never gunna happen.

which it decides on vs that which it doesn't, and u haven't done that.
i think what's got u all worked up is u seem to have produced what is
technically a total decider, in that it has some definite return for
all input machines ... but it's certainly _not_ a total halting
decider as demonstrated bc of ur example.

i'm working on a specification for an effectively total halting
classifier that captures all machines we're interested in, but not
technically a total halting decider. i've called it a partial halting
recognizer, and i'm trying to specifically justify the logic on where
it does and does not manage to recognize a halting input machine, and
more importantly why we can accept when it does not recognize all
input machines:

I have done more than that.

   𝓱p = (m: machine) -> {
     true: if m halts and not depends on any n where 𝓱p(n)->false
     false: otherwise
   }

u can't use runtime inf recursion detection to get around the
undecidability of the halting problem, no matter how many times u
repeat the same thing, or hide it beneath increasingly more proof-
like phrasing

the problem of constructing paradoxical dependencies that is
inherent to computing prevents this

whatever innovation is to had on the matter is going to be in-
spite of that limitation, not by denying or removing it

--
arising us out of the computing dark ages,
please excuse my pseudo-pyscript,
~ the lil crank that could
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.theory

dart200 wrote:

On 10/11/26 5:46 AM, olcott wrote:

On 10/10/2026 10:40 PM, dart200 wrote:

On 10/10/26 6:02 PM, olcott wrote:

On 10/10/2026 7:53 PM, dart200 wrote:

On 10/10/26 2:24 PM, olcott wrote:

On 10/10/2026 3:52 PM, dart200 wrote:

On 10/10/26 1:17 PM, olcott wrote:

https://github.com/plolcott/x86utm/blob/master/Halt7.c
https://github.com/plolcott/x86utm/blob/master/README.md

*Succinct proof that the Halting Problem Theorem is incorrect* >>>>>>>>
Axiom 1 --- Paraphrase of Emil Post
All computations are essentially the application of finite string >>>>>>>> transformation rules to finite string inputs to derive any and all >>>>>>>> outputs. All computations are only allowed to apply finite string >>>>>>>> transformations to their finite string inputs.

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

Axiom 3
This is a single unique sequence thus making every other
sequence incorrect.

Axiom 4
This sequence does not derive the behavior of DD() executed from >>>>>>>> main().
HHH cannot report on the behavior of its caller DD().

Axiom 5
DD correctly simulated by HHH cannot possibly reach its simulated >>>>>>>> final halt state is determined by the execution trace shown below. >>>>>>>>
Conclusion
Simulating halt decider HHH is applied to the conventional
Halting Problem proof counter-example finite string input DD.
HHH applies Emil Post finite string transformations to this DD. >>>>>>>> Because the input is C source code correct transformations must >>>>>>>> correspond to the operational semantics of the C programming
language. The above prohibits HHH from reporting on the behavior >>>>>>>> of its caller DD() directly executed in main(). This also enables >>>>>>>> HHH to correctly reject its input finite string DD as non-halting. >>>>>>>>
typedef int (*ptr)();
int HHH(ptr P);

01 int DD()
02 {
03   int Halt_Status = HHH(DD);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }
08
09 void main()
10 {
11  HHH(DD);
12 }

Correct simulation is defined as DD simulated by HHH according >>>>>>>> to the (operational) semantics of the C programming language. >>>>>>>> Ordinary software engineering conclusively proves that DD
correctly simulated by HHH cannot possibly reach its own
simulated return instruction and terminate normally.

Execution Trace
Line 11: main() invokes HHH(DD);

keeps repeating (unless aborted)
Line 03: simulated DD() invokes simulated HHH(DD) that simulates >>>>>>>> DD()

Simulation invariant
DD correctly simulated by HHH cannot possibly reach past its own >>>>>>>> line 03 whether or not HHH ever aborts this simulation.

DD correctly simulated by HHH cannot possibly reach its
simulated final state.

bruh ur never gunna build a machine that decides whether any
given input machine halts or not

You did not carefully study the above words that
took me 20,000 hours over 22 years to write.

If you spent 1 / 40,000th of the time that I did
to carefully studying my words you would see how
terrible your paraphrase is.

bragging about time spent ain't a good look dud, no correlation
between time spent and correctness, as unfortunate as that is

HHH(DD)->0 still does not accurately describe the behavior of DD...

Spent 30 minutes reading and re-reading this (2.5 pages)
https://github.com/plolcott/x86utm/blob/master/README.md
before any of your replies will have any actual basis.

ur like trying to deny that water is wet dud

DD is a halting function, no??? HHH(DD)->0 does not indicate that DD
is a halting function, so it doesn't match to DDs true behavior. u
haven't properly justified why that ought to be

i'm almost positive allowing such a thing would allow for a proof
that 1=0 somewhere, and at that point we've lost all consistency in >>>>> reason

It is true that no halt decider can possibly return a halt
status TO ITS CALLER that does the opposite of whatever
it returns. It is also true that NO HALT DECIDER IS EVER
ACCOUNTABLE FOR THE BEHAVIOR OF ITS OWN CALLER.

nah i don't buy that excuse. u need to be able to precisely define
the sets of machines

The set of machines that it decides have always been zero.
It only decides the halting property of finite strings.

My CS professor said a computer can't get pi exactly because it doesn't
have enough memory. Which of the personal computers today has infinite
memory?
--
Do you want a friendship with chaos?
Wanna party with Perses?
Consequences mean nothing to me
Morning is your problem, I don't stick around
The damage is done, it’s all you from here
And don’t come a looking 'cause I simply do not care
Like you’d even find me
Well, maybe after a few pints
And I only make an appearance when the time is right
You see, I'm all about the here and now
Live in the moment and all that, carpe diem
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/11/2026 8:02 AM, dart200 wrote:

On 10/11/26 5:46 AM, olcott wrote:

On 10/10/2026 10:40 PM, dart200 wrote:

On 10/10/26 6:02 PM, olcott wrote:

On 10/10/2026 7:53 PM, dart200 wrote:

On 10/10/26 2:24 PM, olcott wrote:

On 10/10/2026 3:52 PM, dart200 wrote:

On 10/10/26 1:17 PM, olcott wrote:

https://github.com/plolcott/x86utm/blob/master/Halt7.c
https://github.com/plolcott/x86utm/blob/master/README.md

*Succinct proof that the Halting Problem Theorem is incorrect* >>>>>>>>
Axiom 1 --- Paraphrase of Emil Post
All computations are essentially the application of finite string >>>>>>>> transformation rules to finite string inputs to derive any and all >>>>>>>> outputs. All computations are only allowed to apply finite string >>>>>>>> transformations to their finite string inputs.

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

Axiom 3
This is a single unique sequence thus making every other
sequence incorrect.

Axiom 4
This sequence does not derive the behavior of DD() executed from >>>>>>>> main().
HHH cannot report on the behavior of its caller DD().

Axiom 5
DD correctly simulated by HHH cannot possibly reach its simulated >>>>>>>> final halt state is determined by the execution trace shown below. >>>>>>>>
Conclusion
Simulating halt decider HHH is applied to the conventional
Halting Problem proof counter-example finite string input DD.
HHH applies Emil Post finite string transformations to this DD. >>>>>>>> Because the input is C source code correct transformations must >>>>>>>> correspond to the operational semantics of the C programming
language. The above prohibits HHH from reporting on the behavior >>>>>>>> of its caller DD() directly executed in main(). This also enables >>>>>>>> HHH to correctly reject its input finite string DD as non-halting. >>>>>>>>
typedef int (*ptr)();
int HHH(ptr P);

01 int DD()
02 {
03   int Halt_Status = HHH(DD);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }
08
09 void main()
10 {
11  HHH(DD);
12 }

Correct simulation is defined as DD simulated by HHH according >>>>>>>> to the (operational) semantics of the C programming language. >>>>>>>> Ordinary software engineering conclusively proves that DD
correctly simulated by HHH cannot possibly reach its own
simulated return instruction and terminate normally.

Execution Trace
Line 11: main() invokes HHH(DD);

keeps repeating (unless aborted)
Line 03: simulated DD() invokes simulated HHH(DD) that simulates >>>>>>>> DD()

Simulation invariant
DD correctly simulated by HHH cannot possibly reach past its own >>>>>>>> line 03 whether or not HHH ever aborts this simulation.

DD correctly simulated by HHH cannot possibly reach its
simulated final state.

bruh ur never gunna build a machine that decides whether any
given input machine halts or not

You did not carefully study the above words that
took me 20,000 hours over 22 years to write.

If you spent 1 / 40,000th of the time that I did
to carefully studying my words you would see how
terrible your paraphrase is.

bragging about time spent ain't a good look dud, no correlation
between time spent and correctness, as unfortunate as that is

HHH(DD)->0 still does not accurately describe the behavior of DD...

Spent 30 minutes reading and re-reading this (2.5 pages)
https://github.com/plolcott/x86utm/blob/master/README.md
before any of your replies will have any actual basis.

ur like trying to deny that water is wet dud

DD is a halting function, no??? HHH(DD)->0 does not indicate that DD
is a halting function, so it doesn't match to DDs true behavior. u
haven't properly justified why that ought to be

i'm almost positive allowing such a thing would allow for a proof
that 1=0 somewhere, and at that point we've lost all consistency in >>>>> reason

It is true that no halt decider can possibly return a halt
status TO ITS CALLER that does the opposite of whatever
it returns. It is also true that NO HALT DECIDER IS EVER
ACCOUNTABLE FOR THE BEHAVIOR OF ITS OWN CALLER.

nah i don't buy that excuse. u need to be able to precisely define
the sets of machines

The set of machines that it decides have always been zero.
It only decides the halting property of finite strings.

it decides some property that you haven't fully specified.

https://github.com/plolcott/x86utm/blob/master/README.md

Axiom 1
Every halt decider always decides the halting property
of its input finite string. It never decides the halting
property of any executing machine.

it does not
compute/decide the objective total halting map from input machine represented by a finite string to the halting property dud

  𝓱 = (m: machine) -> {
    true: if m halts
    false: otherwise
  }

i can't build that either. never gunna happen.

which it decides on vs that which it doesn't, and u haven't done
that. i think what's got u all worked up is u seem to have produced
what is technically a total decider, in that it has some definite
return for all input machines ... but it's certainly _not_ a total
halting decider as demonstrated bc of ur example.

i'm working on a specification for an effectively total halting
classifier that captures all machines we're interested in, but not
technically a total halting decider. i've called it a partial halting
recognizer, and i'm trying to specifically justify the logic on where
it does and does not manage to recognize a halting input machine, and
more importantly why we can accept when it does not recognize all
input machines:

I have done more than that.

   𝓱p = (m: machine) -> {
     true: if m halts and not depends on any n where 𝓱p(n)->false >>>      false: otherwise
   }

u can't use runtime inf recursion detection to get around the
undecidability of the halting problem, no matter how many times u
repeat the same thing, or hide it beneath increasingly more proof-
like phrasing

the problem of constructing paradoxical dependencies that is
inherent to computing prevents this

whatever innovation is to had on the matter is going to be in-
spite of that limitation, not by denying or removing it

--
Copyright 2026 Olcott

The essence of computation is applying finite
string transformations to finite string inputs
to derive outputs. // paraphrase of Emil Post

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

From Newsgroup: comp.theory

On 10/11/26 6:36 AM, olcott wrote:

On 10/11/2026 8:02 AM, dart200 wrote:

On 10/11/26 5:46 AM, olcott wrote:

On 10/10/2026 10:40 PM, dart200 wrote:

On 10/10/26 6:02 PM, olcott wrote:

On 10/10/2026 7:53 PM, dart200 wrote:

On 10/10/26 2:24 PM, olcott wrote:

On 10/10/2026 3:52 PM, dart200 wrote:

On 10/10/26 1:17 PM, olcott wrote:

https://github.com/plolcott/x86utm/blob/master/Halt7.c
https://github.com/plolcott/x86utm/blob/master/README.md

*Succinct proof that the Halting Problem Theorem is incorrect* >>>>>>>>>
Axiom 1 --- Paraphrase of Emil Post
All computations are essentially the application of finite string >>>>>>>>> transformation rules to finite string inputs to derive any and all >>>>>>>>> outputs. All computations are only allowed to apply finite string >>>>>>>>> transformations to their finite string inputs.

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

Axiom 3
This is a single unique sequence thus making every other
sequence incorrect.

Axiom 4
This sequence does not derive the behavior of DD() executed >>>>>>>>> from main().
HHH cannot report on the behavior of its caller DD().

Axiom 5
DD correctly simulated by HHH cannot possibly reach its simulated >>>>>>>>> final halt state is determined by the execution trace shown below. >>>>>>>>>
Conclusion
Simulating halt decider HHH is applied to the conventional
Halting Problem proof counter-example finite string input DD. >>>>>>>>> HHH applies Emil Post finite string transformations to this DD. >>>>>>>>> Because the input is C source code correct transformations must >>>>>>>>> correspond to the operational semantics of the C programming >>>>>>>>> language. The above prohibits HHH from reporting on the behavior >>>>>>>>> of its caller DD() directly executed in main(). This also enables >>>>>>>>> HHH to correctly reject its input finite string DD as non-halting. >>>>>>>>>
typedef int (*ptr)();
int HHH(ptr P);

01 int DD()
02 {
03   int Halt_Status = HHH(DD);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }
08
09 void main()
10 {
11  HHH(DD);
12 }

Correct simulation is defined as DD simulated by HHH according >>>>>>>>> to the (operational) semantics of the C programming language. >>>>>>>>> Ordinary software engineering conclusively proves that DD
correctly simulated by HHH cannot possibly reach its own
simulated return instruction and terminate normally.

Execution Trace
Line 11: main() invokes HHH(DD);

keeps repeating (unless aborted)
Line 03: simulated DD() invokes simulated HHH(DD) that
simulates DD()

Simulation invariant
DD correctly simulated by HHH cannot possibly reach past its >>>>>>>>> own line 03 whether or not HHH ever aborts this simulation.

DD correctly simulated by HHH cannot possibly reach its
simulated final state.

bruh ur never gunna build a machine that decides whether any
given input machine halts or not

You did not carefully study the above words that
took me 20,000 hours over 22 years to write.

If you spent 1 / 40,000th of the time that I did
to carefully studying my words you would see how
terrible your paraphrase is.

bragging about time spent ain't a good look dud, no correlation
between time spent and correctness, as unfortunate as that is

HHH(DD)->0 still does not accurately describe the behavior of DD... >>>>>

Spent 30 minutes reading and re-reading this (2.5 pages)
https://github.com/plolcott/x86utm/blob/master/README.md
before any of your replies will have any actual basis.

ur like trying to deny that water is wet dud

DD is a halting function, no??? HHH(DD)->0 does not indicate that DD
is a halting function, so it doesn't match to DDs true behavior. u
haven't properly justified why that ought to be

i'm almost positive allowing such a thing would allow for a proof >>>>>> that 1=0 somewhere, and at that point we've lost all consistency
in reason

It is true that no halt decider can possibly return a halt
status TO ITS CALLER that does the opposite of whatever
it returns. It is also true that NO HALT DECIDER IS EVER
ACCOUNTABLE FOR THE BEHAVIOR OF ITS OWN CALLER.

nah i don't buy that excuse. u need to be able to precisely define
the sets of machines

The set of machines that it decides have always been zero.
It only decides the halting property of finite strings.

it decides some property that you haven't fully specified.

https://github.com/plolcott/x86utm/blob/master/README.md

Axiom 1
Every halt decider always decides the halting property
of its input finite string. It never decides the halting
property of any executing machine.

bruh, ur trying to redefine the halting property of the input string to
not match the halting behavior of the machine represented by that
string... in order to declare this HHH as a total halting decider???

no one is gunna accept that dud. the information that anyone cares about
is the halting behavior of the machine represented by that input string.

 it does not compute/decide the objective total halting map from input
machine represented by a finite string to the halting property dud

   𝓱 = (m: machine) -> {
     true: if m halts
     false: otherwise
   }

i can't build that either. never gunna happen.

which it decides on vs that which it doesn't, and u haven't done
that. i think what's got u all worked up is u seem to have produced
what is technically a total decider, in that it has some definite
return for all input machines ... but it's certainly _not_ a total
halting decider as demonstrated bc of ur example.

i'm working on a specification for an effectively total halting
classifier that captures all machines we're interested in, but not
technically a total halting decider. i've called it a partial
halting recognizer, and i'm trying to specifically justify the logic
on where it does and does not manage to recognize a halting input
machine, and more importantly why we can accept when it does not
recognize all input machines:

I have done more than that.

   𝓱p = (m: machine) -> {
     true: if m halts and not depends on any n where 𝓱p(n)->false >>>>      false: otherwise
   }

see i'm not redefining was it means for the input string m that
represents a machine to halt ,in order to get this working. "m halts"
means that when the instructions specified by m are executed, the
resulting computation is finite.

the "and not depends on any n where 𝓱p(n)->false" is an additional specification that is independent of whether "m halts". once explained,
it clearly delineates an additional criteria of machine m, for 𝓱p to
return true. i'm not just redefining what "m halts" means

u can't use runtime inf recursion detection to get around the
undecidability of the halting problem, no matter how many times u >>>>>> repeat the same thing, or hide it beneath increasingly more proof- >>>>>> like phrasing

the problem of constructing paradoxical dependencies that is
inherent to computing prevents this

whatever innovation is to had on the matter is going to be in- >>>>>>>> spite of that limitation, not by denying or removing it

--
arising us out of the computing dark ages,
please excuse my pseudo-pyscript,
~ the lil crank that could
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/11/2026 11:03 AM, dart200 wrote:

On 10/11/26 6:36 AM, olcott wrote:

On 10/11/2026 8:02 AM, dart200 wrote:

On 10/11/26 5:46 AM, olcott wrote:

On 10/10/2026 10:40 PM, dart200 wrote:

On 10/10/26 6:02 PM, olcott wrote:

On 10/10/2026 7:53 PM, dart200 wrote:

On 10/10/26 2:24 PM, olcott wrote:

On 10/10/2026 3:52 PM, dart200 wrote:

On 10/10/26 1:17 PM, olcott wrote:

https://github.com/plolcott/x86utm/blob/master/Halt7.c
https://github.com/plolcott/x86utm/blob/master/README.md

*Succinct proof that the Halting Problem Theorem is incorrect* >>>>>>>>>>
Axiom 1 --- Paraphrase of Emil Post
All computations are essentially the application of finite string >>>>>>>>>> transformation rules to finite string inputs to derive any and >>>>>>>>>> all
outputs. All computations are only allowed to apply finite string >>>>>>>>>> transformations to their finite string inputs.

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

Axiom 3
This is a single unique sequence thus making every other
sequence incorrect.

Axiom 4
This sequence does not derive the behavior of DD() executed >>>>>>>>>> from main().
HHH cannot report on the behavior of its caller DD().

Axiom 5
DD correctly simulated by HHH cannot possibly reach its simulated >>>>>>>>>> final halt state is determined by the execution trace shown >>>>>>>>>> below.

Conclusion
Simulating halt decider HHH is applied to the conventional >>>>>>>>>> Halting Problem proof counter-example finite string input DD. >>>>>>>>>> HHH applies Emil Post finite string transformations to this DD. >>>>>>>>>> Because the input is C source code correct transformations must >>>>>>>>>> correspond to the operational semantics of the C programming >>>>>>>>>> language. The above prohibits HHH from reporting on the behavior >>>>>>>>>> of its caller DD() directly executed in main(). This also enables >>>>>>>>>> HHH to correctly reject its input finite string DD as non- >>>>>>>>>> halting.

typedef int (*ptr)();
int HHH(ptr P);

01 int DD()
02 {
03   int Halt_Status = HHH(DD);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }
08
09 void main()
10 {
11  HHH(DD);
12 }

Correct simulation is defined as DD simulated by HHH according >>>>>>>>>> to the (operational) semantics of the C programming language. >>>>>>>>>> Ordinary software engineering conclusively proves that DD >>>>>>>>>> correctly simulated by HHH cannot possibly reach its own
simulated return instruction and terminate normally.

Execution Trace
Line 11: main() invokes HHH(DD);

keeps repeating (unless aborted)
Line 03: simulated DD() invokes simulated HHH(DD) that
simulates DD()

Simulation invariant
DD correctly simulated by HHH cannot possibly reach past its >>>>>>>>>> own line 03 whether or not HHH ever aborts this simulation. >>>>>>>>>>
DD correctly simulated by HHH cannot possibly reach its
simulated final state.

bruh ur never gunna build a machine that decides whether any >>>>>>>>> given input machine halts or not

You did not carefully study the above words that
took me 20,000 hours over 22 years to write.

If you spent 1 / 40,000th of the time that I did
to carefully studying my words you would see how
terrible your paraphrase is.

bragging about time spent ain't a good look dud, no correlation >>>>>>> between time spent and correctness, as unfortunate as that is

HHH(DD)->0 still does not accurately describe the behavior of DD... >>>>>>

Spent 30 minutes reading and re-reading this (2.5 pages)
https://github.com/plolcott/x86utm/blob/master/README.md
before any of your replies will have any actual basis.

ur like trying to deny that water is wet dud

DD is a halting function, no??? HHH(DD)->0 does not indicate that
DD is a halting function, so it doesn't match to DDs true behavior. >>>>> u haven't properly justified why that ought to be

i'm almost positive allowing such a thing would allow for a proof >>>>>>> that 1=0 somewhere, and at that point we've lost all consistency >>>>>>> in reason

It is true that no halt decider can possibly return a halt
status TO ITS CALLER that does the opposite of whatever
it returns. It is also true that NO HALT DECIDER IS EVER
ACCOUNTABLE FOR THE BEHAVIOR OF ITS OWN CALLER.

nah i don't buy that excuse. u need to be able to precisely define
the sets of machines

The set of machines that it decides have always been zero.
It only decides the halting property of finite strings.

it decides some property that you haven't fully specified.

https://github.com/plolcott/x86utm/blob/master/README.md

Axiom 1
Every halt decider always decides the halting property
of its input finite string. It never decides the halting
property of any executing machine.

bruh, ur trying to redefine the halting property of the input string to
not match the halting behavior of the machine represented by that
string... in order to declare this HHH as a total halting decider???

no one is gunna accept that dud. the information that anyone cares about
is the halting behavior of the machine represented by that input string.

Let's not get personal.'This is valid due to Flibble's Law:

If a problem permits infinite behavior in its formulation, it permits
infinite analysis of that behavior in its decidability scope.

/Flibble

 it does not compute/decide the objective total halting map from
input machine represented by a finite string to the halting property dud >>>
   𝓱 = (m: machine) -> {
     true: if m halts
     false: otherwise
   }

i can't build that either. never gunna happen.

which it decides on vs that which it doesn't, and u haven't done
that. i think what's got u all worked up is u seem to have produced >>>>> what is technically a total decider, in that it has some definite
return for all input machines ... but it's certainly _not_ a total
halting decider as demonstrated bc of ur example.

i'm working on a specification for an effectively total halting
classifier that captures all machines we're interested in, but not
technically a total halting decider. i've called it a partial
halting recognizer, and i'm trying to specifically justify the
logic on where it does and does not manage to recognize a halting
input machine, and more importantly why we can accept when it does
not recognize all input machines:

I have done more than that.

   𝓱p = (m: machine) -> {
     true: if m halts and not depends on any n where 𝓱p(n)->false >>>>>      false: otherwise
   }

see i'm not redefining was it means for the input string m that
represents a machine to halt ,in order to get this working. "m halts"
means that when the instructions specified by m are executed, the
resulting computation is finite.

the "and not depends on any n where 𝓱p(n)->false" is an additional specification that is independent of whether "m halts". once explained,
it clearly delineates an additional criteria of machine m, for 𝓱p to return true. i'm not just redefining what "m halts" means

u can't use runtime inf recursion detection to get around the
undecidability of the halting problem, no matter how many times u >>>>>>> repeat the same thing, or hide it beneath increasingly more
proof- like phrasing

the problem of constructing paradoxical dependencies that is >>>>>>>>> inherent to computing prevents this

whatever innovation is to had on the matter is going to be in- >>>>>>>>> spite of that limitation, not by denying or removing it

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.theory

olcott wrote:

All computations are essentially the application of finite string

Finite but unbounded. The string can grow beyond the currently allocated
space and if halts, it will eventually reach its maximum but you do not
know when. Or if.
--
Siri Seal of Disavowal #777-000. Disavowed. Denied. @
NO KINGS For I desire mercy not sacrifice. /|\
The Church of the Holey Apple .signature 5.5 / \
of Discordian Mysteries. This post insults Islam. Mohamed
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/13/2026 3:42 AM, chine.bleu wrote:

olcott wrote:

All computations are essentially the application of finite string

Finite but unbounded. The string can grow beyond the currently allocated space and if halts, it will eventually reach its maximum but you do not
know when. Or if.

I don't think that this extra detail materially effects
any aspect of my proof so it seems true and irrelevant.
--
Copyright 2026 Olcott

The essence of computation is applying finite
string transformations to finite string inputs
to derive outputs. // paraphrase of Emil Post

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

From Newsgroup: comp.theory

On 10/10/2026 23:17, olcott wrote:

https://github.com/plolcott/x86utm/blob/master/Halt7.c https://github.com/plolcott/x86utm/blob/master/README.md

*Succinct proof that the Halting Problem Theorem is incorrect*

Axiom 1 --- Paraphrase of Emil Post
All computations are essentially the application of finite string transformation rules to finite string inputs to derive any and all
outputs. All computations are only allowed to apply finite string transformations to their finite string inputs.

That axiom is false. A computation is allowed to do whatever a
computation can do. The correct statement could be that a process
that does something other than a transformation of one finite
string to another is not a computation. But there is no prohibition
of such processes.

From a false axiom a false claim can be proven.

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

That is not a useful axiom. The operational semantics of C prigramming
language says very little about finite strings. The most important
aspect is that a finite string is an array of small integers. The
exact meaning of "small" is not specified but it must include at
least -128 .. 127 or 0 .. 255. The integer 0 has a special meaning
as most standard library operations interprete and use it as the mark
for the logical end of the string.

Axiom 3
This is a single unique sequence thus making every other sequence
incorrect.

An axiom shold not contain a pronoun that refers to something outside
of the axiom. It should also not contain any consequence of anything,
and therfore not words like "thus" or "therefore".

Axiom 4
This sequence does not derive the behavior of DD() executed from main().
HHH cannot report on the behavior of its caller DD().

Pronouns that refer to outside of the axiom should not be used as
adjectives, either.

Axiom 5
DD correctly simulated by HHH cannot possibly reach its simulated
final halt state is determined by the execution trace shown below.

Conclusion

Simulating halt decider HHH is applied to the conventional
Halting Problem proof counter-example finite string input DD.
HHH applies Emil Post finite string transformations to this DD.
Because the input is C source code correct transformations must
correspond to the operational semantics of the C programming
language. The above prohibits HHH from reporting on the behavior
of its caller DD() directly executed in main(). This also enables
HHH to correctly reject its input finite string DD as non-halting.

Conclusion is derived (correctly or otherwise) from axioms that needn't
be true in the context of the halting theorem. Therefore the conclusion
is not relevant to the halting problem.

If at least one proof of the halting theorem is sound then the theorem
is true. Consequntly, the halting problem is true unless in every proof
of it there is a false assumption or invalid inference.
--
Mikko
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 11/10/2026 16:25, Blaine wrote:

dart200 wrote:

On 10/11/26 5:46 AM, olcott wrote:

On 10/10/2026 10:40 PM, dart200 wrote:

On 10/10/26 6:02 PM, olcott wrote:

On 10/10/2026 7:53 PM, dart200 wrote:

On 10/10/26 2:24 PM, olcott wrote:

On 10/10/2026 3:52 PM, dart200 wrote:

On 10/10/26 1:17 PM, olcott wrote:

https://github.com/plolcott/x86utm/blob/master/Halt7.c
https://github.com/plolcott/x86utm/blob/master/README.md

*Succinct proof that the Halting Problem Theorem is incorrect* >>>>>>>>>
Axiom 1 --- Paraphrase of Emil Post
All computations are essentially the application of finite string >>>>>>>>> transformation rules to finite string inputs to derive any and all >>>>>>>>> outputs. All computations are only allowed to apply finite string >>>>>>>>> transformations to their finite string inputs.

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

Axiom 3
This is a single unique sequence thus making every other
sequence incorrect.

Axiom 4
This sequence does not derive the behavior of DD() executed >>>>>>>>> from main().
HHH cannot report on the behavior of its caller DD().

Axiom 5
DD correctly simulated by HHH cannot possibly reach its simulated >>>>>>>>> final halt state is determined by the execution trace shown below. >>>>>>>>>
Conclusion
Simulating halt decider HHH is applied to the conventional
Halting Problem proof counter-example finite string input DD. >>>>>>>>> HHH applies Emil Post finite string transformations to this DD. >>>>>>>>> Because the input is C source code correct transformations must >>>>>>>>> correspond to the operational semantics of the C programming >>>>>>>>> language. The above prohibits HHH from reporting on the behavior >>>>>>>>> of its caller DD() directly executed in main(). This also enables >>>>>>>>> HHH to correctly reject its input finite string DD as non-halting. >>>>>>>>>
typedef int (*ptr)();
int HHH(ptr P);

01 int DD()
02 {
03   int Halt_Status = HHH(DD);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }
08
09 void main()
10 {
11  HHH(DD);
12 }

Correct simulation is defined as DD simulated by HHH according >>>>>>>>> to the (operational) semantics of the C programming language. >>>>>>>>> Ordinary software engineering conclusively proves that DD
correctly simulated by HHH cannot possibly reach its own
simulated return instruction and terminate normally.

Execution Trace
Line 11: main() invokes HHH(DD);

keeps repeating (unless aborted)
Line 03: simulated DD() invokes simulated HHH(DD) that
simulates DD()

Simulation invariant
DD correctly simulated by HHH cannot possibly reach past its >>>>>>>>> own line 03 whether or not HHH ever aborts this simulation.

DD correctly simulated by HHH cannot possibly reach its
simulated final state.

bruh ur never gunna build a machine that decides whether any
given input machine halts or not

You did not carefully study the above words that
took me 20,000 hours over 22 years to write.

If you spent 1 / 40,000th of the time that I did
to carefully studying my words you would see how
terrible your paraphrase is.

bragging about time spent ain't a good look dud, no correlation
between time spent and correctness, as unfortunate as that is

HHH(DD)->0 still does not accurately describe the behavior of DD... >>>>>

Spent 30 minutes reading and re-reading this (2.5 pages)
https://github.com/plolcott/x86utm/blob/master/README.md
before any of your replies will have any actual basis.

ur like trying to deny that water is wet dud

DD is a halting function, no??? HHH(DD)->0 does not indicate that DD
is a halting function, so it doesn't match to DDs true behavior. u
haven't properly justified why that ought to be

i'm almost positive allowing such a thing would allow for a proof >>>>>> that 1=0 somewhere, and at that point we've lost all consistency
in reason

It is true that no halt decider can possibly return a halt
status TO ITS CALLER that does the opposite of whatever
it returns. It is also true that NO HALT DECIDER IS EVER
ACCOUNTABLE FOR THE BEHAVIOR OF ITS OWN CALLER.

nah i don't buy that excuse. u need to be able to precisely define
the sets of machines

The set of machines that it decides have always been zero.
It only decides the halting property of finite strings.

My CS professor said a computer can't get pi exactly because it doesn't
have enough memory. Which of the personal computers today has infinite memory?

None. But if you pay an infinte amount of money we could build one
and deliver within an infinite time after the payment.
--
Mikko

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/20/2026 3:10 AM, Mikko wrote:

On 10/10/2026 23:17, olcott wrote:

https://github.com/plolcott/x86utm/blob/master/Halt7.c
https://github.com/plolcott/x86utm/blob/master/README.md

*Succinct proof that the Halting Problem Theorem is incorrect*

Axiom 1 --- Paraphrase of Emil Post
All computations are essentially the application of finite string
transformation rules to finite string inputs to derive any and all
outputs. All computations are only allowed to apply finite string
transformations to their finite string inputs.

That axiom is false. A computation is allowed to do whatever a
computation can do. The correct statement could be that a process
that does something other than a transformation of one finite
string to another is not a computation. But there is no prohibition
of such processes.

*Improved wording*
Axiom 1 --- Paraphrase of Emil Post definition of computation
All computations are equivalent to the application of finite string transformation rules to finite string inputs to derive any and all
outputs.

From a false axiom a false claim can be proven.

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

That is not a useful axiom.

It is the key to understanding how computation actually works
and finding its true limits if there are any.

Axiom 2
Computation inherently requires relevant rather than arbitrary
finite string transformations. To determine the sum of 2 + 3
relevant steps must be performed.

The term-of-the-art definition of a decider ignores this and
includes computations that ignore their input and simply halt.
We are augmenting this: A decider must apply finite string
transformations to its finite string input that are relevant
to the decision criteria.

A decider that accepts a finite string of integer values as
within the ASCII uppercase alphabetic range of 65 to 90 must
actually examine its input for these values.

A halt decider must apply finite string transformations to
its finite string input that are semantically relevant to
determining the halting property specified by this finite
string input.

Halt decider H must apply finite string transformations to
finite string input D strictly according to the operational
semantics of the source language of the computation. This
applies universally to all models of computation, including
the source code of Turing Machines.

The operational semantics of C prigramming
language says very little about finite strings.

01 int DD()
02 {
03 int Halt_Status = HHH(DD);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }

The operational semantics of C programming language
does say that DD cannot ignore its own line 03 and
jump to its own line 06.

The most important
aspect is that a finite string is an array of small integers. The
exact meaning of "small" is not specified but it must include at
least -128 .. 127 or 0 .. 255. The integer 0 has a special meaning
as most standard library operations interprete and use it as the mark
for the logical end of the string.

Axiom 3
This is a single unique sequence thus making every other sequence
incorrect.

An axiom shold not contain a pronoun that refers to something outside
of the axiom. It should also not contain any consequence of anything,
and therfore not words like "thus" or "therefore".

My first axioms is universally accepted and my second one is
self-evidently correct. Without this self-evidence then
"where are you getting this from" would be unanswered.

Axiom 4
This sequence does not derive the behavior of DD() executed from main().
HHH cannot report on the behavior of its caller DD().

Lets just keep working on 2 until you get that it is self-evidently
correct. It is the foundation of all of the rest.

Pronouns that refer to outside of the axiom should not be used as
adjectives, either.

Axiom 5
DD correctly simulated by HHH cannot possibly reach its simulated
final halt state is determined by the execution trace shown below.

Conclusion

Simulating halt decider HHH is applied to the conventional
Halting Problem proof counter-example finite string input DD.
HHH applies Emil Post finite string transformations to this DD.
Because the input is C source code correct transformations must
correspond to the operational semantics of the C programming
language. The above prohibits HHH from reporting on the behavior
of its caller DD() directly executed in main(). This also enables
HHH to correctly reject its input finite string DD as non-halting.

Conclusion is derived (correctly or otherwise) from axioms that needn't
be true in the context of the halting theorem. Therefore the conclusion
is not relevant to the halting problem.

If at least one proof of the halting theorem is sound then the theorem
is true. Consequntly, the halting problem is true unless in every proof
of it there is a false assumption or invalid inference.

--
Copyright 2026 Olcott

*Succinct refutation of the Halting Theorem* https://github.com/plolcott/x86utm/blob/master/README.md


The essence of computation is applying finite
string transformations to finite string inputs
to derive outputs. // paraphrase of Emil Post

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

From Newsgroup: comp.theory

On 20/10/2026 18:00, olcott wrote:

On 10/20/2026 3:10 AM, Mikko wrote:

On 10/10/2026 23:17, olcott wrote:

https://github.com/plolcott/x86utm/blob/master/Halt7.c
https://github.com/plolcott/x86utm/blob/master/README.md

*Succinct proof that the Halting Problem Theorem is incorrect*

Axiom 1 --- Paraphrase of Emil Post
All computations are essentially the application of finite string
transformation rules to finite string inputs to derive any and all
outputs. All computations are only allowed to apply finite string
transformations to their finite string inputs.

That axiom is false. A computation is allowed to do whatever a
computation can do. The correct statement could be that a process
that does something other than a transformation of one finite
string to another is not a computation. But there is no prohibition
of such processes.

*Improved wording*
Axiom 1 --- Paraphrase of Emil Post definition of computation
All computations are equivalent to the application of finite string transformation rules to finite string inputs to derive any and all
outputs.

The source should be stated after the axiom, not before.

 From a false axiom a false claim can be proven.

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

That is not a useful axiom.

It is the key to understanding how computation actually works
and finding its true limits if there are any.

It isn't if its only content is an opionion about correcteness of
actions of some named things without relating that opinion or
those things to actual working of conmputations.

Axiom 2
Computation inherently requires relevant rather than arbitrary
finite string transformations. To determine the sum of 2 + 3
relevant steps must be performed.

So you rejected your old axiom 2?
--
Mikko
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/21/2026 3:25 AM, Mikko wrote:

On 20/10/2026 18:00, olcott wrote:

On 10/20/2026 3:10 AM, Mikko wrote:

On 10/10/2026 23:17, olcott wrote:

https://github.com/plolcott/x86utm/blob/master/Halt7.c
https://github.com/plolcott/x86utm/blob/master/README.md

*Succinct proof that the Halting Problem Theorem is incorrect*

Axiom 1 --- Paraphrase of Emil Post
All computations are essentially the application of finite string
transformation rules to finite string inputs to derive any and all
outputs. All computations are only allowed to apply finite string
transformations to their finite string inputs.

That axiom is false. A computation is allowed to do whatever a
computation can do. The correct statement could be that a process
that does something other than a transformation of one finite
string to another is not a computation. But there is no prohibition
of such processes.

*Improved wording*
Axiom 1 --- Paraphrase of Emil Post definition of computation
All computations are equivalent to the application of finite string
transformation rules to finite string inputs to derive any and all
outputs.

The source should be stated after the axiom, not before.

I am the source. I made his work completely generic so that
so that it could be better understood as universally applicable.

 From a false axiom a false claim can be proven.

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

That is not a useful axiom.

It is the key to understanding how computation actually works
and finding its true limits if there are any.

It isn't if its only content is an opionion about correcteness of
actions of some named things without relating that opinion or
those things to actual working of conmputations.

I am making truth itself computable.
All of my ideas are either self-evidently
correct or are semantically entailed by
self-evidently correct ideas.

Axiom 2
Computation inherently requires relevant rather than arbitrary
finite string transformations. To determine the sum of 2 + 3
relevant steps must be performed.

So you rejected your old axiom 2?

Clarifications and simplifications pertaining to

communication effectiveness not objective correctness.
The essence of my ideas have been consistently correct
since 2004.
--
Copyright 2026 Olcott

*Succinct refutation of the Halting Theorem* https://github.com/plolcott/x86utm/blob/master/README.md


The essence of computation is applying finite
string transformations to finite string inputs
to derive outputs. // paraphrase of Emil Post

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