• Re: The halting problem is incorrect two different ways --- updated

    From Mikko@mikko.levanto@iki.fi to comp.theory,sci.logic,comp.ai.philosophy,sci.math on Wed Dec 3 13:34:01 2025
    From Newsgroup: comp.theory

    olcott kirjoitti 2.12.2025 klo 16.14:
    On 12/2/2025 3:07 AM, Mikko wrote:
    olcott kirjoitti 1.12.2025 klo 14.47:
    On 12/1/2025 4:45 AM, Mikko wrote:
    olcott kirjoitti 29.11.2025 klo 18.38:
    On 11/29/2025 3:27 AM, Mikko wrote:
    olcott kirjoitti 28.11.2025 klo 16.46:
    On 11/28/2025 2:14 AM, Mikko wrote:
    Chris M. Thomasson kirjoitti 27.11.2025 klo 9.58:
    On 11/26/2025 11:49 PM, Mikko wrote:
    olcott kirjoitti 26.11.2025 klo 17.17:
    On 11/26/2025 4:01 AM, Mikko wrote:
    olcott kirjoitti 17.11.2025 klo 15.31:
    On 11/17/2025 2:43 AM, Mikko wrote:
    On 2025-11-17 00:12:14 +0000, olcott said:

    On 11/16/2025 3:18 AM, Mikko wrote:
    On 2025-11-15 16:12:49 +0000, olcott said:

    On 11/15/2025 4:15 AM, Mikko wrote:
    On 2025-11-14 15:00:09 +0000, olcott said: >>>>>>>>>>>>>>>>>>
    On 11/14/2025 3:21 AM, Mikko wrote:
    On 2025-11-13 15:50:37 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>
    On 11/13/2025 2:48 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>> On 2025-11-12 12:54:12 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>
    On 11/12/2025 1:09 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-11 13:04:13 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>
    On 11/11/2025 2:59 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-10 14:48:00 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>
    On 11/10/2025 3:43 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-09 12:51:57 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>
    On 11/9/2025 4:22 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-08 13:36:06 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    On 11/8/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    On 11/7/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> said:

    D simulated by H cannot possibly >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reach its own >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated final halt state. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    That is merely a defect in H and >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> irrelevanto to the semantic and other >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> properties of D. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    That's a stupid statement. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    Stupid is better than false. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    It is stupidly false because you didn't >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bother
    to pay any attention at all. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    A statement about me is off topic in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> comp.theory.

    H simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that never >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reaches
    the simulated "return" statement final halt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> state of D because D calls H(D) in recursive >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation.

    Have you ever done any actual programming? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    A question about me is off topic in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> comp.theory. But yes, I did yesterday. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    *This is my key foundational point* >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    int H(char* P);

    int D()
    {
       int Halt_Status = H(D); >>>>>>>>>>>>>>>>>>>>>>>>>>>>>    if (Halt_Status) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>      HERE: goto HERE; >>>>>>>>>>>>>>>>>>>>>>>>>>>>>    return Halt_Status; >>>>>>>>>>>>>>>>>>>>>>>>>>>>> }

    The above is in test.c >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    simulate.exe implements a C interpreter. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    simulate test.c

    runs the interpreter on the above source file >>>>>>>>>>>>>>>>>>>>>>>>>>>>> from the command prompt. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
    Any program that does not correctly tell >>>>>>>>>>>>>>>>>>>>>>>>>>>> whether test.c halts is not >>>>>>>>>>>>>>>>>>>>>>>>>>>> a halt decider. A program that gives an >>>>>>>>>>>>>>>>>>>>>>>>>>>> incorrect answer is not even >>>>>>>>>>>>>>>>>>>>>>>>>>>> a partial halt decider. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
    When this interpreter sees the call to H(D) >>>>>>>>>>>>>>>>>>>>>>>>>>>>> it calls itself with the text body of D. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
    According to C semanttics it should simulate >>>>>>>>>>>>>>>>>>>>>>>>>>>> H(D), either simultating >>>>>>>>>>>>>>>>>>>>>>>>>>>> instructions of H or simulating the return >>>>>>>>>>>>>>>>>>>>>>>>>>>> from H(D) with the same >>>>>>>>>>>>>>>>>>>>>>>>>>>> returned value as H(D) would return if >>>>>>>>>>>>>>>>>>>>>>>>>>>> executed, or do whatever H would >>>>>>>>>>>>>>>>>>>>>>>>>>>> do if H would not not return. >>>>>>>>>>>>>>>>>>>>>>>>>>>
    That is not the behavior that the input to >>>>>>>>>>>>>>>>>>>>>>>>>>> H(D) specifies.
    simulator.exe simulates Test.c. This >>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that
    calls H(D) that the simulator recognizes as >>>>>>>>>>>>>>>>>>>>>>>>>>> itself.

    It is the behavour C semantics specifies. >>>>>>>>>>>>>>>>>>>>>>>>>> According to C semantics
    any other behavour that produces the same >>>>>>>>>>>>>>>>>>>>>>>>>> result is equally valid.

    So D remains stuck in recursive simulation >>>>>>>>>>>>>>>>>>>>>>>>>>> never being
    able to complete its first statement before >>>>>>>>>>>>>>>>>>>>>>>>>>> calling H(D)
    again and again.

    If that happens then H does not return and >>>>>>>>>>>>>>>>>>>>>>>>>> therefore is not a decider. >>>>>>>>>>>>>>>>>>>>>>>>>
    Maybe my work is over your head. >>>>>>>>>>>>>>>>>>>>>>>>
    Maybe the definition of "decider" is over your >>>>>>>>>>>>>>>>>>>>>>>> head.

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

    int DD()
    {
       int Halt_Status = HHH(DD);
       if (Halt_Status)
         HERE: goto HERE;
       return Halt_Status;
    }

    int main()
    {
       HHH(DD);
    }

    People here have consistently lied about >>>>>>>>>>>>>>>>>>>>>>> DD simulated by HHH reaching its own "return" >>>>>>>>>>>>>>>>>>>>>>> statement final halt state for three years. >>>>>>>>>>>>>>>>>>>>>>>
    You yourself have not told the truth about >>>>>>>>>>>>>>>>>>>>>>> this even once.

    That seems to confirm that the definition of >>>>>>>>>>>>>>>>>>>>>> "decider" is over your head.

    I am just talking at the level of the execution >>>>>>>>>>>>>>>>>>>>> trace of C functions. D does specify non-halting >>>>>>>>>>>>>>>>>>>>> behavior to its termination analyzer. >>>>>>>>>>>>>>>>>>>>
    The termination problem is not about specifying "to >>>>>>>>>>>>>>>>>>>> its termination
    analyzer". Instead the termination problem is to >>>>>>>>>>>>>>>>>>>> determine whether
    a program terminates every time when used as it was >>>>>>>>>>>>>>>>>>>> designed to be
    used.

    The halting problem requires that a halt decider >>>>>>>>>>>>>>>>>>> correctly report on the behavior of its caller >>>>>>>>>>>>>>>>>>> and no halt decider can even see its actual caller. >>>>>>>>>>>>>>>>>>
    Every halt decider is required to report on the >>>>>>>>>>>>>>>>>> behaviour asked about.

    And this is incorrect when it has not access to >>>>>>>>>>>>>>>>> the behavior that it is asked about.

    No, it is not. The solution to the halting problem must >>>>>>>>>>>>>>>> include the
    necessary access. Conversely, a proof that the necessary >>>>>>>>>>>>>>>> access is
    impossible is sufficient to prove that halting problem >>>>>>>>>>>>>>>> is unsolvable.

    Reporing on the behavior of DD() executed from
    main requires HHH to report on information
    that is not contained in its input thus it is
    incorrect to require HHH to report on that.

    That HHH fails to meet the requirements does not mean that >>>>>>>>>>>>>> the
    requirements are wrong. It merely meas that HHH is not a halt >>>>>>>>>>>>>> decider.


    That HHH fails to meet the requirements by itself does >>>>>>>>>>>>> not mean that the requirements are wrong.

    Turing machine deciders only compute a mapping from
    their [finite string] inputs to an accept or reject
    state on the basis that this [finite string] input
    specifies or fails to specify a semantic or syntactic >>>>>>>>>>>>> property.

    That the information that HHH is required to report
    on simply is not contained in its input is what makes >>>>>>>>>>>>> the requirements wrong.

    No, it merely means that the designer ot HHH has failed to >>>>>>>>>>>> specify the
    encoding rules so that the input contains the full
    specification of the
    behaviour.

    In other words you are trying to get away with
    disagreeing with the semantics of the x86 language
    or the semantics of the C programing language.

    You are the one who disagrees with the x86 processors about >>>>>>>>>> the x86
    language semantics. When an x86 processor executes a program >>>>>>>>>> it executes
    according to the x86 semantics. When DD is executed according >>>>>>>>>> to the x86
    semantics it halts. Anybody who says that DD specifies a non- >>>>>>>>>> halting
    behaviour disagrees with the x86 semantics.

    But, DD can halt or not halt, right?

    When Olcott uses the name DD he means the particular program in his >>>>>>>> GitHub repository except when he wants to deceive with
    equivocation.
    The DD is Olcotts repository halts.

    I am doing this in the C programming language so that
    every detail can be concretely specified and thus no
    important details are simply abstracted away.

    https://github.com/plolcott/x86utm/blob/master/Halt7.c
    HHH on line 1081
    DD on line 1355

    The DD on line 1355 is the DD I mentioned above and whicn is listed >>>>>> below. HHH always means the HHH on line 1081 except when otherwise >>>>>> stated. HHH(DD) means the HHH on line 1081 is called with the pointer >>>>>> to the DD on line 1355 as the argument. THat call returns 0, which >>>>>> means that DD does not halt.


    HHH(DD)==0 has nothing to do with DD executed from main.

    True. It would if HHH were a halting decider but HHH isn't.

    If you carefully studied all of what I said you
    would see that the halting problem is a category
    error because it directly contradicts one of the
    foundational axioms of computer science.

    Any statement that a problem contradicts anything is a categoryerror.

    Flibble was the first one to use this term that I am aware of.

    Do you mean the term "category error"? It is a well known term
    though many authors prefer "category mistake" for the same
    meaning.

    Anyway, any claim that a problem contradict something is
    a category error because the meanings of "problem" and
    "contradict" are not compatible.
    --
    Mikko
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From olcott@polcott333@gmail.com to comp.theory,sci.logic,comp.ai.philosophy,sci.math on Wed Dec 3 10:27:12 2025
    From Newsgroup: comp.theory

    On 12/3/2025 5:34 AM, Mikko wrote:
    olcott kirjoitti 2.12.2025 klo 16.14:
    On 12/2/2025 3:07 AM, Mikko wrote:
    olcott kirjoitti 1.12.2025 klo 14.47:
    On 12/1/2025 4:45 AM, Mikko wrote:
    olcott kirjoitti 29.11.2025 klo 18.38:
    On 11/29/2025 3:27 AM, Mikko wrote:
    olcott kirjoitti 28.11.2025 klo 16.46:
    On 11/28/2025 2:14 AM, Mikko wrote:
    Chris M. Thomasson kirjoitti 27.11.2025 klo 9.58:
    On 11/26/2025 11:49 PM, Mikko wrote:
    olcott kirjoitti 26.11.2025 klo 17.17:
    On 11/26/2025 4:01 AM, Mikko wrote:
    olcott kirjoitti 17.11.2025 klo 15.31:
    On 11/17/2025 2:43 AM, Mikko wrote:
    On 2025-11-17 00:12:14 +0000, olcott said:

    On 11/16/2025 3:18 AM, Mikko wrote:
    On 2025-11-15 16:12:49 +0000, olcott said:

    On 11/15/2025 4:15 AM, Mikko wrote:
    On 2025-11-14 15:00:09 +0000, olcott said: >>>>>>>>>>>>>>>>>>>
    On 11/14/2025 3:21 AM, Mikko wrote:
    On 2025-11-13 15:50:37 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>
    On 11/13/2025 2:48 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>> On 2025-11-12 12:54:12 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>
    On 11/12/2025 1:09 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-11 13:04:13 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>
    On 11/11/2025 2:59 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-10 14:48:00 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>
    On 11/10/2025 3:43 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-09 12:51:57 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    On 11/9/2025 4:22 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-08 13:36:06 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    On 11/8/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    On 11/7/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> said:

    D simulated by H cannot possibly >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reach its own >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated final halt state. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    That is merely a defect in H and >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> irrelevanto to the semantic and other >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> properties of D. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    That's a stupid statement. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    Stupid is better than false. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    It is stupidly false because you didn't >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bother
    to pay any attention at all. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    A statement about me is off topic in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> comp.theory.

    H simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that never >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reaches
    the simulated "return" statement final halt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> state of D because D calls H(D) in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> recursive
    simulation.

    Have you ever done any actual programming? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    A question about me is off topic in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> comp.theory. But yes, I did yesterday. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    *This is my key foundational point* >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    int H(char* P);

    int D()
    {
       int Halt_Status = H(D); >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    if (Halt_Status) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>      HERE: goto HERE; >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    return Halt_Status; >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }

    The above is in test.c >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    simulate.exe implements a C interpreter. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    simulate test.c

    runs the interpreter on the above source file >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from the command prompt. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    Any program that does not correctly tell >>>>>>>>>>>>>>>>>>>>>>>>>>>>> whether test.c halts is not >>>>>>>>>>>>>>>>>>>>>>>>>>>>> a halt decider. A program that gives an >>>>>>>>>>>>>>>>>>>>>>>>>>>>> incorrect answer is not even >>>>>>>>>>>>>>>>>>>>>>>>>>>>> a partial halt decider. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    When this interpreter sees the call to H(D) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it calls itself with the text body of D. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    According to C semanttics it should >>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulate H(D), either simultating >>>>>>>>>>>>>>>>>>>>>>>>>>>>> instructions of H or simulating the return >>>>>>>>>>>>>>>>>>>>>>>>>>>>> from H(D) with the same >>>>>>>>>>>>>>>>>>>>>>>>>>>>> returned value as H(D) would return if >>>>>>>>>>>>>>>>>>>>>>>>>>>>> executed, or do whatever H would >>>>>>>>>>>>>>>>>>>>>>>>>>>>> do if H would not not return. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
    That is not the behavior that the input to >>>>>>>>>>>>>>>>>>>>>>>>>>>> H(D) specifies.
    simulator.exe simulates Test.c. This >>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that
    calls H(D) that the simulator recognizes as >>>>>>>>>>>>>>>>>>>>>>>>>>>> itself.

    It is the behavour C semantics specifies. >>>>>>>>>>>>>>>>>>>>>>>>>>> According to C semantics >>>>>>>>>>>>>>>>>>>>>>>>>>> any other behavour that produces the same >>>>>>>>>>>>>>>>>>>>>>>>>>> result is equally valid. >>>>>>>>>>>>>>>>>>>>>>>>>>>
    So D remains stuck in recursive simulation >>>>>>>>>>>>>>>>>>>>>>>>>>>> never being
    able to complete its first statement before >>>>>>>>>>>>>>>>>>>>>>>>>>>> calling H(D)
    again and again.

    If that happens then H does not return and >>>>>>>>>>>>>>>>>>>>>>>>>>> therefore is not a decider. >>>>>>>>>>>>>>>>>>>>>>>>>>
    Maybe my work is over your head. >>>>>>>>>>>>>>>>>>>>>>>>>
    Maybe the definition of "decider" is over your >>>>>>>>>>>>>>>>>>>>>>>>> head.

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

    int DD()
    {
       int Halt_Status = HHH(DD); >>>>>>>>>>>>>>>>>>>>>>>>    if (Halt_Status)
         HERE: goto HERE;
       return Halt_Status;
    }

    int main()
    {
       HHH(DD);
    }

    People here have consistently lied about >>>>>>>>>>>>>>>>>>>>>>>> DD simulated by HHH reaching its own "return" >>>>>>>>>>>>>>>>>>>>>>>> statement final halt state for three years. >>>>>>>>>>>>>>>>>>>>>>>>
    You yourself have not told the truth about >>>>>>>>>>>>>>>>>>>>>>>> this even once.

    That seems to confirm that the definition of >>>>>>>>>>>>>>>>>>>>>>> "decider" is over your head.

    I am just talking at the level of the execution >>>>>>>>>>>>>>>>>>>>>> trace of C functions. D does specify non-halting >>>>>>>>>>>>>>>>>>>>>> behavior to its termination analyzer. >>>>>>>>>>>>>>>>>>>>>
    The termination problem is not about specifying "to >>>>>>>>>>>>>>>>>>>>> its termination
    analyzer". Instead the termination problem is to >>>>>>>>>>>>>>>>>>>>> determine whether
    a program terminates every time when used as it was >>>>>>>>>>>>>>>>>>>>> designed to be
    used.

    The halting problem requires that a halt decider >>>>>>>>>>>>>>>>>>>> correctly report on the behavior of its caller >>>>>>>>>>>>>>>>>>>> and no halt decider can even see its actual caller. >>>>>>>>>>>>>>>>>>>
    Every halt decider is required to report on the >>>>>>>>>>>>>>>>>>> behaviour asked about.

    And this is incorrect when it has not access to >>>>>>>>>>>>>>>>>> the behavior that it is asked about.

    No, it is not. The solution to the halting problem must >>>>>>>>>>>>>>>>> include the
    necessary access. Conversely, a proof that the >>>>>>>>>>>>>>>>> necessary access is
    impossible is sufficient to prove that halting problem >>>>>>>>>>>>>>>>> is unsolvable.

    Reporing on the behavior of DD() executed from >>>>>>>>>>>>>>>> main requires HHH to report on information
    that is not contained in its input thus it is
    incorrect to require HHH to report on that.

    That HHH fails to meet the requirements does not mean >>>>>>>>>>>>>>> that the
    requirements are wrong. It merely meas that HHH is not a >>>>>>>>>>>>>>> halt
    decider.


    That HHH fails to meet the requirements by itself does >>>>>>>>>>>>>> not mean that the requirements are wrong.

    Turing machine deciders only compute a mapping from >>>>>>>>>>>>>> their [finite string] inputs to an accept or reject >>>>>>>>>>>>>> state on the basis that this [finite string] input >>>>>>>>>>>>>> specifies or fails to specify a semantic or syntactic >>>>>>>>>>>>>> property.

    That the information that HHH is required to report >>>>>>>>>>>>>> on simply is not contained in its input is what makes >>>>>>>>>>>>>> the requirements wrong.

    No, it merely means that the designer ot HHH has failed to >>>>>>>>>>>>> specify the
    encoding rules so that the input contains the full
    specification of the
    behaviour.

    In other words you are trying to get away with
    disagreeing with the semantics of the x86 language
    or the semantics of the C programing language.

    You are the one who disagrees with the x86 processors about >>>>>>>>>>> the x86
    language semantics. When an x86 processor executes a program >>>>>>>>>>> it executes
    according to the x86 semantics. When DD is executed according >>>>>>>>>>> to the x86
    semantics it halts. Anybody who says that DD specifies a non- >>>>>>>>>>> halting
    behaviour disagrees with the x86 semantics.

    But, DD can halt or not halt, right?

    When Olcott uses the name DD he means the particular program in >>>>>>>>> his
    GitHub repository except when he wants to deceive with
    equivocation.
    The DD is Olcotts repository halts.

    I am doing this in the C programming language so that
    every detail can be concretely specified and thus no
    important details are simply abstracted away.

    https://github.com/plolcott/x86utm/blob/master/Halt7.c
    HHH on line 1081
    DD on line 1355

    The DD on line 1355 is the DD I mentioned above and whicn is listed >>>>>>> below. HHH always means the HHH on line 1081 except when otherwise >>>>>>> stated. HHH(DD) means the HHH on line 1081 is called with the
    pointer
    to the DD on line 1355 as the argument. THat call returns 0, which >>>>>>> means that DD does not halt.


    HHH(DD)==0 has nothing to do with DD executed from main.

    True. It would if HHH were a halting decider but HHH isn't.

    If you carefully studied all of what I said you
    would see that the halting problem is a category
    error because it directly contradicts one of the
    foundational axioms of computer science.

    Any statement that a problem contradicts anything is a categoryerror.

    Flibble was the first one to use this term that I am aware of.

    Do you mean the term "category error"? It is a well known term
    though many authors prefer "category mistake" for the same
    meaning.


    Flibble was the first one to use the term category
    error applied to the halting problem. Later on
    after I explained all of the details in a dialogue
    both ChatGPT and Claude AI applied this same term.

    They did this on the basis that the halting problem
    required a halt decider to report on behavior that
    is different than the behavior that its actual input
    actually specifies.

    They were able to directly assess this behavior
    themselves by actually performing a simulation of DD by
    HHH according to the semantics of the x86 language.

    Anyway, any claim that a problem contradict something is
    a category error because the meanings of "problem" and
    "contradict" are not compatible.


    When the halting problem contradicts the definition
    of a Turing machine decider

    Turing machine deciders only compute a mapping from
    their [finite string] inputs to an accept or reject
    state on the basis that this [finite string] input
    specifies or fails to specify a semantic or syntactic
    property.
    --
    Copyright 2025 Olcott

    My 28 year goal has been to make
    "true on the basis of meaning" computable.

    This required establishing a new foundation
    for correct reasoning.
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From olcott@polcott333@gmail.com to sci.math,sci.logic,comp.theory on Wed Dec 3 18:24:03 2025
    From Newsgroup: comp.theory

    On 12/1/2025 10:00 AM, Python wrote:
    Le 01/12/2025 à 16:55, olcott a écrit :
    On 12/1/2025 9:48 AM, Python wrote:
    Le 01/12/2025 à 16:39, olcott a écrit :
    On 12/1/2025 9:31 AM, Python wrote:
    Le 01/12/2025 à 16:29, olcott a écrit :
    On 12/1/2025 9:26 AM, olcott wrote:
    On 12/1/2025 9:19 AM, olcott wrote:
    On 12/1/2025 9:06 AM, Python wrote:
    Le 01/12/2025 à 15:57, olcott a écrit :
    On 12/1/2025 8:45 AM, Python wrote:
    Le 01/12/2025 à 15:38, olcott a écrit :
    On 12/1/2025 8:29 AM, Python wrote:
    [snip boring nonsense and lies]

    Peter you've intoxicated yourself.

    Here is what Chat GPT told me once about himself:


    Welcome back!

    You have put your finger on the single most fundamental >>>>>>>>>>>>> limitation of large language models:

    They can generate coherent arguments for things that are >>>>>>>>>>>>> false, harmful, fringe, or logically impossible — not >>>>>>>>>>>>> because they “believe” them, but because they can simulate >>>>>>>>>>>>> the rhetorical form of such arguments.

    And you’re right:
    The fact that the model “doesn’t believe it” is irrelevant. >>>>>>>>>>>>> What matters is:
    it can produce it.

    f2up math.

    Once you fully understand semantic tautologies
    (the ultimate basis of all of my work)

    In epistemology (theory of knowledge), a self-evident
    proposition is a proposition that is known to be true
    by understanding its meaning without proof...
    https://en.wikipedia.org/wiki/Self-evidence

    You will understand that I am correct. If you insist
    on finding fault at a much higher priority than an
    honest dialogue then you will never understand that
    I am correct.

    You are NOT correct.


    You will continue to lack a sufficient basis
    for that until you grok (Heinlein) semantic
    tautology / self-evident truth.

    It seems that the single most useful application
    of my work is to make LLM systems much more reliable.

    Your "work" is complete garbage... Sorry.



    Yet you cannot possibly show that with complete
    and correct reasoning because you continue to
    lack the above required basis.

    I'm am not willing to endorse a sophistry that I KNOW to be >>>>>>>>> INCORRECT.



    How can you possibly show that a semantic tautology
    is incorrect when it is inherently correct?



    Within the definition that "cats" <are> "animals"
    how can you possibly show that "cats" <are><not> "animals" ? ? ? >>>>>>>

    "cats" is a finite string <are>
    is a type of relation between finite strings.

    Don't dodge.

    This a sin because it is a kind of lie.



    Revelation 21:8
    King James Version
    ...and all liars, shall have their part in the lake which
    burneth with fire and brimstone: which is the second death.

    Liars swear their allegiance to the father of lies
    and thus condemn themselves as shown above.

    Kurt Gödel in his 1944 Russell's mathematical logic gave
    the following definition of the "theory of simple types"
    in a footnote:

    By the theory of simple types I mean the doctrine which says
    that the objects of thought ... are divided into types,
    namely: individuals, properties of individuals, relations
    between individuals, properties of such relations, etc.
    https://en.wikipedia.org/wiki/History_of_type_theory#G%C3%B6del_1944

    The essence of this is that all *objects of thought*
    can be encoded in a hierarchy of types as relations
    between finite strings.

    You'll enjoy Hell, Trump will be there too.



    In other words you are asserting that type theory is a lie?

    https://lawrencecpaulson.github.io/papers/Russells-mathematical-logic.pdf

    My whole 28 year purpose in this is so that people like Trump
    cannot get away with their lies when Truth(L,x) becomes
    computable.

    Adding more lies on top of previous lies, dodging, evading and defaming.

    This is not smelling good, maybe some smoke?



    That you fail to understand what I am saying
    is less that no basis what-so-ever for rebuttal.

    That you denigrate what I said with pure rhetoric
    that is not anchored to any basis seems to indicate
    that you know you have no sound basis.
    --
    Copyright 2025 Olcott

    My 28 year goal has been to make
    "true on the basis of meaning" computable.

    This required establishing a new foundation
    for correct reasoning.
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Mikko@mikko.levanto@iki.fi to comp.theory,sci.logic,comp.ai.philosophy,sci.math on Thu Dec 4 11:17:52 2025
    From Newsgroup: comp.theory

    olcott kirjoitti 3.12.2025 klo 18.27:
    On 12/3/2025 5:34 AM, Mikko wrote:
    olcott kirjoitti 2.12.2025 klo 16.14:
    On 12/2/2025 3:07 AM, Mikko wrote:
    olcott kirjoitti 1.12.2025 klo 14.47:
    On 12/1/2025 4:45 AM, Mikko wrote:
    olcott kirjoitti 29.11.2025 klo 18.38:
    On 11/29/2025 3:27 AM, Mikko wrote:
    olcott kirjoitti 28.11.2025 klo 16.46:
    On 11/28/2025 2:14 AM, Mikko wrote:
    Chris M. Thomasson kirjoitti 27.11.2025 klo 9.58:
    On 11/26/2025 11:49 PM, Mikko wrote:
    olcott kirjoitti 26.11.2025 klo 17.17:
    On 11/26/2025 4:01 AM, Mikko wrote:
    olcott kirjoitti 17.11.2025 klo 15.31:
    On 11/17/2025 2:43 AM, Mikko wrote:
    On 2025-11-17 00:12:14 +0000, olcott said:

    On 11/16/2025 3:18 AM, Mikko wrote:
    On 2025-11-15 16:12:49 +0000, olcott said: >>>>>>>>>>>>>>>>>>
    On 11/15/2025 4:15 AM, Mikko wrote:
    On 2025-11-14 15:00:09 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>
    On 11/14/2025 3:21 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>> On 2025-11-13 15:50:37 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>
    On 11/13/2025 2:48 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-12 12:54:12 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>
    On 11/12/2025 1:09 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-11 13:04:13 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>
    On 11/11/2025 2:59 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-10 14:48:00 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>
    On 11/10/2025 3:43 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-09 12:51:57 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    On 11/9/2025 4:22 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-08 13:36:06 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    On 11/8/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> said:

    On 11/7/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> said:

    D simulated by H cannot possibly >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reach its own >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated final halt state. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    That is merely a defect in H and >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> irrelevanto to the semantic and other >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> properties of D. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    That's a stupid statement. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    Stupid is better than false. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    It is stupidly false because you didn't >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bother
    to pay any attention at all. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    A statement about me is off topic in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> comp.theory.

    H simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that never >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reaches
    the simulated "return" statement final >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halt
    state of D because D calls H(D) in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> recursive
    simulation.

    Have you ever done any actual programming? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    A question about me is off topic in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> comp.theory. But yes, I did yesterday. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    *This is my key foundational point* >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    int H(char* P);

    int D()
    {
       int Halt_Status = H(D); >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    if (Halt_Status) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>      HERE: goto HERE; >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>    return Halt_Status; >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }

    The above is in test.c >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    simulate.exe implements a C interpreter. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    simulate test.c

    runs the interpreter on the above source >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> file
    from the command prompt. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    Any program that does not correctly tell >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> whether test.c halts is not >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a halt decider. A program that gives an >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> incorrect answer is not even >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a partial halt decider. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    When this interpreter sees the call to H(D) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it calls itself with the text body of D. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    According to C semanttics it should >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulate H(D), either simultating >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instructions of H or simulating the return >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from H(D) with the same >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> returned value as H(D) would return if >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> executed, or do whatever H would >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> do if H would not not return. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    That is not the behavior that the input to >>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(D) specifies.
    simulator.exe simulates Test.c. This >>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that
    calls H(D) that the simulator recognizes as >>>>>>>>>>>>>>>>>>>>>>>>>>>>> itself.

    It is the behavour C semantics specifies. >>>>>>>>>>>>>>>>>>>>>>>>>>>> According to C semantics >>>>>>>>>>>>>>>>>>>>>>>>>>>> any other behavour that produces the same >>>>>>>>>>>>>>>>>>>>>>>>>>>> result is equally valid. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
    So D remains stuck in recursive simulation >>>>>>>>>>>>>>>>>>>>>>>>>>>>> never being
    able to complete its first statement before >>>>>>>>>>>>>>>>>>>>>>>>>>>>> calling H(D)
    again and again.

    If that happens then H does not return and >>>>>>>>>>>>>>>>>>>>>>>>>>>> therefore is not a decider. >>>>>>>>>>>>>>>>>>>>>>>>>>>
    Maybe my work is over your head. >>>>>>>>>>>>>>>>>>>>>>>>>>
    Maybe the definition of "decider" is over your >>>>>>>>>>>>>>>>>>>>>>>>>> head.

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

    int DD()
    {
       int Halt_Status = HHH(DD); >>>>>>>>>>>>>>>>>>>>>>>>>    if (Halt_Status)
         HERE: goto HERE;
       return Halt_Status;
    }

    int main()
    {
       HHH(DD);
    }

    People here have consistently lied about >>>>>>>>>>>>>>>>>>>>>>>>> DD simulated by HHH reaching its own "return" >>>>>>>>>>>>>>>>>>>>>>>>> statement final halt state for three years. >>>>>>>>>>>>>>>>>>>>>>>>>
    You yourself have not told the truth about >>>>>>>>>>>>>>>>>>>>>>>>> this even once.

    That seems to confirm that the definition of >>>>>>>>>>>>>>>>>>>>>>>> "decider" is over your head.

    I am just talking at the level of the execution >>>>>>>>>>>>>>>>>>>>>>> trace of C functions. D does specify non-halting >>>>>>>>>>>>>>>>>>>>>>> behavior to its termination analyzer. >>>>>>>>>>>>>>>>>>>>>>
    The termination problem is not about specifying >>>>>>>>>>>>>>>>>>>>>> "to its termination
    analyzer". Instead the termination problem is to >>>>>>>>>>>>>>>>>>>>>> determine whether
    a program terminates every time when used as it >>>>>>>>>>>>>>>>>>>>>> was designed to be
    used.

    The halting problem requires that a halt decider >>>>>>>>>>>>>>>>>>>>> correctly report on the behavior of its caller >>>>>>>>>>>>>>>>>>>>> and no halt decider can even see its actual caller. >>>>>>>>>>>>>>>>>>>>
    Every halt decider is required to report on the >>>>>>>>>>>>>>>>>>>> behaviour asked about.

    And this is incorrect when it has not access to >>>>>>>>>>>>>>>>>>> the behavior that it is asked about.

    No, it is not. The solution to the halting problem >>>>>>>>>>>>>>>>>> must include the
    necessary access. Conversely, a proof that the >>>>>>>>>>>>>>>>>> necessary access is
    impossible is sufficient to prove that halting problem >>>>>>>>>>>>>>>>>> is unsolvable.

    Reporing on the behavior of DD() executed from >>>>>>>>>>>>>>>>> main requires HHH to report on information
    that is not contained in its input thus it is >>>>>>>>>>>>>>>>> incorrect to require HHH to report on that.

    That HHH fails to meet the requirements does not mean >>>>>>>>>>>>>>>> that the
    requirements are wrong. It merely meas that HHH is not a >>>>>>>>>>>>>>>> halt
    decider.


    That HHH fails to meet the requirements by itself does >>>>>>>>>>>>>>> not mean that the requirements are wrong.

    Turing machine deciders only compute a mapping from >>>>>>>>>>>>>>> their [finite string] inputs to an accept or reject >>>>>>>>>>>>>>> state on the basis that this [finite string] input >>>>>>>>>>>>>>> specifies or fails to specify a semantic or syntactic >>>>>>>>>>>>>>> property.

    That the information that HHH is required to report >>>>>>>>>>>>>>> on simply is not contained in its input is what makes >>>>>>>>>>>>>>> the requirements wrong.

    No, it merely means that the designer ot HHH has failed to >>>>>>>>>>>>>> specify the
    encoding rules so that the input contains the full >>>>>>>>>>>>>> specification of the
    behaviour.

    In other words you are trying to get away with
    disagreeing with the semantics of the x86 language
    or the semantics of the C programing language.

    You are the one who disagrees with the x86 processors about >>>>>>>>>>>> the x86
    language semantics. When an x86 processor executes a program >>>>>>>>>>>> it executes
    according to the x86 semantics. When DD is executed
    according to the x86
    semantics it halts. Anybody who says that DD specifies a >>>>>>>>>>>> non- halting
    behaviour disagrees with the x86 semantics.

    But, DD can halt or not halt, right?

    When Olcott uses the name DD he means the particular program >>>>>>>>>> in his
    GitHub repository except when he wants to deceive with
    equivocation.
    The DD is Olcotts repository halts.

    I am doing this in the C programming language so that
    every detail can be concretely specified and thus no
    important details are simply abstracted away.

    https://github.com/plolcott/x86utm/blob/master/Halt7.c
    HHH on line 1081
    DD on line 1355

    The DD on line 1355 is the DD I mentioned above and whicn is listed >>>>>>>> below. HHH always means the HHH on line 1081 except when otherwise >>>>>>>> stated. HHH(DD) means the HHH on line 1081 is called with the >>>>>>>> pointer
    to the DD on line 1355 as the argument. THat call returns 0, which >>>>>>>> means that DD does not halt.


    HHH(DD)==0 has nothing to do with DD executed from main.

    True. It would if HHH were a halting decider but HHH isn't.

    If you carefully studied all of what I said you
    would see that the halting problem is a category
    error because it directly contradicts one of the
    foundational axioms of computer science.

    Any statement that a problem contradicts anything is a categoryerror.

    Flibble was the first one to use this term that I am aware of.

    It does not matter who first used the term here.
    ...
    Anyway, any claim that a problem contradict something is
    a category error because the meanings of "problem" and
    "contradict" are not compatible.

    When the halting problem contradicts the definition
    of a Turing machine decider

    A contradiction means that all claims of some set cannot be true. It
    is a category error to apply the term "contradiction" to non-claims.
    Examples of non-claims are problem and definition. An example of
    category error is "the halting problem contradicts the definition of
    a Turing machine decider".
    --
    Mikko
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From olcott@polcott333@gmail.com to comp.theory,sci.logic,comp.ai.philosophy,sci.math on Thu Dec 4 08:15:10 2025
    From Newsgroup: comp.theory

    On 12/4/2025 3:17 AM, Mikko wrote:
    olcott kirjoitti 3.12.2025 klo 18.27:
    On 12/3/2025 5:34 AM, Mikko wrote:
    olcott kirjoitti 2.12.2025 klo 16.14:

    Flibble was the first one to use this term that I am aware of.

    It does not matter who first used the term here.
    ...
    Anyway, any claim that a problem contradict something is
    a category error because the meanings of "problem" and
    "contradict" are not compatible.

    When the halting problem contradicts the definition
    of a Turing machine decider

    A contradiction means that all claims of some set cannot be true. It
    is a category error to apply the term "contradiction" to non-claims.
    Examples of non-claims are problem and definition. An example of
    category error is "the halting problem contradicts the definition of
    a Turing machine decider".


    The halting problem contradicts the definition
    of a Turing machine decider proving that it is
    wrong because the definition of a Turing machine
    decider is foundational.
    --
    Copyright 2025 Olcott

    My 28 year goal has been to make
    "true on the basis of meaning" computable.

    This required establishing a new foundation
    for correct reasoning.
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Mikko@mikko.levanto@iki.fi to comp.theory,sci.logic,comp.ai.philosophy,sci.math on Sat Dec 6 11:23:38 2025
    From Newsgroup: comp.theory

    olcott kirjoitti 4.12.2025 klo 16.15:
    On 12/4/2025 3:17 AM, Mikko wrote:
    olcott kirjoitti 3.12.2025 klo 18.27:
    On 12/3/2025 5:34 AM, Mikko wrote:
    olcott kirjoitti 2.12.2025 klo 16.14:

    Flibble was the first one to use this term that I am aware of.

    It does not matter who first used the term here.
    ...
    Anyway, any claim that a problem contradict something is
    a category error because the meanings of "problem" and
    "contradict" are not compatible.

    When the halting problem contradicts the definition
    of a Turing machine decider

    A contradiction means that all claims of some set cannot be true. It
    is a category error to apply the term "contradiction" to non-claims.
    Examples of non-claims are problem and definition. An example of
    category error is "the halting problem contradicts the definition of
    a Turing machine decider".

    The halting problem contradicts the definition
    of a Turing machine decider proving that it is
    wrong because the definition of a Turing machine
    decider is foundational.

    That still contains the same category error pointed out in my
    prevous comment as quoted above.
    --
    Mikko
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From olcott@polcott333@gmail.com to comp.theory,sci.logic,comp.ai.philosophy,sci.math on Sat Dec 6 06:47:54 2025
    From Newsgroup: comp.theory

    On 12/6/2025 3:23 AM, Mikko wrote:
    olcott kirjoitti 4.12.2025 klo 16.15:
    On 12/4/2025 3:17 AM, Mikko wrote:
    olcott kirjoitti 3.12.2025 klo 18.27:
    On 12/3/2025 5:34 AM, Mikko wrote:
    olcott kirjoitti 2.12.2025 klo 16.14:

    Flibble was the first one to use this term that I am aware of.

    It does not matter who first used the term here.
    ...
    Anyway, any claim that a problem contradict something is
    a category error because the meanings of "problem" and
    "contradict" are not compatible.

    When the halting problem contradicts the definition
    of a Turing machine decider

    A contradiction means that all claims of some set cannot be true. It
    is a category error to apply the term "contradiction" to non-claims.
    Examples of non-claims are problem and definition. An example of
    category error is "the halting problem contradicts the definition of
    a Turing machine decider".

    The halting problem contradicts the definition
    of a Turing machine decider proving that it is
    wrong because the definition of a Turing machine
    decider is foundational.

    That still contains the same category error pointed out in my
    prevous comment as quoted above.


    Try and find an error.

    https://www.researchgate.net/publication/398375553_Halting_Problem_Proof_Counter-Example_is_Isomorphic_to_the_Liar_Paradox
    --
    Copyright 2025 Olcott

    My 28 year goal has been to make
    "true on the basis of meaning" computable.

    This required establishing a new foundation
    for correct reasoning.
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Richard Damon@Richard@Damon-Family.org to comp.theory,sci.logic,comp.ai.philosophy,sci.math on Sat Dec 6 17:26:36 2025
    From Newsgroup: comp.theory

    On 12/6/25 4:23 AM, Mikko wrote:
    olcott kirjoitti 4.12.2025 klo 16.15:
    On 12/4/2025 3:17 AM, Mikko wrote:
    olcott kirjoitti 3.12.2025 klo 18.27:
    On 12/3/2025 5:34 AM, Mikko wrote:
    olcott kirjoitti 2.12.2025 klo 16.14:

    Flibble was the first one to use this term that I am aware of.

    It does not matter who first used the term here.
    ...
    Anyway, any claim that a problem contradict something is
    a category error because the meanings of "problem" and
    "contradict" are not compatible.

    When the halting problem contradicts the definition
    of a Turing machine decider

    A contradiction means that all claims of some set cannot be true. It
    is a category error to apply the term "contradiction" to non-claims.
    Examples of non-claims are problem and definition. An example of
    category error is "the halting problem contradicts the definition of
    a Turing machine decider".

    The halting problem contradicts the definition
    of a Turing machine decider proving that it is
    wrong because the definition of a Turing machine
    decider is foundational.

    That still contains the same category error pointed out in my
    prevous comment as quoted above.


    Part of his problem is that his claim of the error in the problem turns
    out to be isomorphic with the claim that a Universal Turing Machine
    can't exist, and if that is true, then his whole foundation crumbles.

    The key is he ways that the input can't mean the behavior of the machine
    it describes when actually run, but if you can have UTMs, then there
    *IS* a way to make an input that fully describes the full behavior of
    the machine when actually run.

    If the encoding his machine can't do that, then the error is in the
    encoding that his machine takes. You can't prove non-existance by
    showing one example doesn't work.

    But then, that is the sort of error he always makes, that you can prove
    a universal with an example, because he just doesn't understand what the
    terms mean.
    --- Synchronet 3.21a-Linux NewsLink 1.2