On 10/31/2026 3:12 AM, Mikko wrote:
On 30/10/2026 14:54, olcott wrote:
On 10/30/2026 4:04 AM, Mikko wrote:
On 29/10/2026 14:36, olcott wrote:
On 10/29/2026 3:45 AM, Mikko wrote:
On 24/10/2026 16:53, olcott wrote:
On 10/24/2026 2:55 AM, Mikko wrote:
On 07/10/2026 15:25, polcott wrote:
On 10/7/2026 5:40 AM, Mikko wrote:
On 02/10/2026 15:28, olcott wrote:
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()
No, it isn't. The halting problem says nothing about "DD()" or >>>>>>>>> "main()".
The halting problem asks "How can one determine whether a
computation
halts?"
Here is the same thing from Linz where H and ?.embedded_H are
also based on UTM simulation of their inputs.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
?.q0 ??? ?* ?.embedded_H ??? ??? ?* ?.ì, // accept state
?.q0 ??? ?* ?.embedded_H ??? ??? ?* ?.qn // reject state
I.e., there is nothing about "DD()" or "main()", just as I said. >>>>>>> Though Linz says nothing about "embedded_H", either; that is
your own interpolation. And you omitted important parts of the
definition.
?.q0 ??? // plays the same role as DD() executed from main()
Having the same role does not mean being the same.
It means isomorphic that means that the Linz proof
can be explained by my proof.
There is no need to explain Linz's proof. Readers are assumed to already >>> know what a proof is (if necessary, they can find that in other boods).
It is easy to see that that proof is correct. Similar proofs with the
same conclusion are shown in other books, and some people may find one
of them even easier to check.
What may need to an explanation is the exact meaning of the conclusion.
?.q0 ??? ?* ?.embedded_H ??? ??? ?* ?.ì, // accept state
?.q0 ??? ?* ?.embedded_H ??? ??? ?* ?.qn // reject state
I show that DD correctly simulated by HHH
cannot possibly reach its own final state.
In the other diecussions we have already noted tyat you only "show"
that with the fallacy of equivocation.
01 int DD()
02 {
03 int Halt_Status = HHH(DD);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
DD simulated by HHH according to the operational semantics
of the C programming language cannot possibly reach its own
simulated return statement while being simulated by HHH.
*If you don't know what a C interpreter is then say so*
*THE ONLY ACCEPTABLE REBUTTAL*
show exactly how DD reaches its return statement
on line 06 while DD is being simulated by HHH
EVERYTHING ELSE IS A DISHONEST DODGE AWAY FROM THE POINT
EVERYTHING ELSE IS A DISHONEST DODGE AWAY FROM THE POINT
EVERYTHING ELSE IS A DISHONEST DODGE AWAY FROM THE POINT
--
Copyright 2026 Olcott
Computation(Olcott)
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.
Because Post canonical systems are Turing-equivalent, anything
that cannot be derived by applying finite string transformations
to finite strings is outside the scope of Church?Turing computation.
Decider(Olcott)
Correcting the misnomer term-of-the-art: decider
Every Decider(Olcott) must apply finite string transformation
inference steps to their finite string inputs that are relevant
to the decision criteria. It must make its decision on this basis.
Halt Decider(Olcott)
Decider(Olcott) entails that Halt Decider(Olcott) H(D) must apply
finite-string inference steps according to the operational semantics
of the source-code computation language of D. The only way to determine
the halting property of a finite string input is to examine the same
beha