1. Forum
  2. Fidonet
  3. COMP.LANG.C

  • Re: The halting problem is incorrect two different ways

    From olcott@3:633/10 to All on Wed Nov 26 22:58:45 2025
    On 11/26/2025 10:48 PM, Mike Terry wrote:
    On 27/11/2025 04:19, Kaz Kylheku wrote:
    On 2025-11-27, olcott <polcott333@gmail.com> wrote:
    The chief editor of one of the most prestigious
    computer science journals exchanged about 15
    emails with me. The bottom line was that he
    could not understand the x86 language well enough.

    LOL; the obvious interpretation of that is "I will say anything
    for you to stop e-mailing me, you sick crank".


    Or... the chief editor really was ignorant of the x86 instruction set!
    Yes, you'd think that someone in his role would have an idea about how processors work (executing instructions, and all that stuff) and have
    some familiarity with x86, but apparently not!

    But don't worry - PO is in the process of making a C-interpreter version
    of his argument.ÿ Then the editor will have no problem understanding
    PO's argument - you just wait and see!

    Or will he?ÿ If the chief editor is an ignorant dumbo

    Then he wouldn't have been the chief editor of
    one of the most prestigious computer science
    journals that exist.

    who's baffled by
    x86, who's to say he won't be equally ignorant of "C"?ÿ In fact, I'll
    bet that's how it will turn out when PO submits is new revised paper.
    [From PO's perspective at least.]ÿ Hehe.


    The key thing about C is that it is simple
    enough that cheaters look ridiculous.

    void DDD()
    {
    HHH(DDD);
    return;
    }

    HHH simulates DDD that calls HHH(DDD)
    that simulates DDD that calls HHH(DDD)...

    How is this DDD going to reach its "return"
    statement by HHH simulating DDD?


    Mike.



    --
    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.

    --- PyGate Linux v1.5.1
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Kaz Kylheku@3:633/10 to All on Thu Nov 27 07:06:33 2025
    On 2025-11-27, olcott <polcott333@gmail.com> wrote:
    On 11/26/2025 10:48 PM, Mike Terry wrote:
    On 27/11/2025 04:19, Kaz Kylheku wrote:
    On 2025-11-27, olcott <polcott333@gmail.com> wrote:
    The chief editor of one of the most prestigious
    computer science journals exchanged about 15
    emails with me. The bottom line was that he
    could not understand the x86 language well enough.

    LOL; the obvious interpretation of that is "I will say anything
    for you to stop e-mailing me, you sick crank".


    Or... the chief editor really was ignorant of the x86 instruction set!
    Yes, you'd think that someone in his role would have an idea about how
    processors work (executing instructions, and all that stuff) and have
    some familiarity with x86, but apparently not!

    But don't worry - PO is in the process of making a C-interpreter version
    of his argument.ÿ Then the editor will have no problem understanding
    PO's argument - you just wait and see!

    Or will he?ÿ If the chief editor is an ignorant dumbo

    Then he wouldn't have been the chief editor of
    one of the most prestigious computer science
    journals that exist.

    who's baffled by
    x86, who's to say he won't be equally ignorant of "C"?ÿ In fact, I'll
    bet that's how it will turn out when PO submits is new revised paper.
    [From PO's perspective at least.]ÿ Hehe.


    The key thing about C is that it is simple
    enough that cheaters look ridiculous.

    You will never be taken seriously if you use languages that are
    completely out of favor in CS academia for doing research in this kind
    of topic.

    You need a language in which a meta-circular interpreter
    (interpreter for that language written in that langauge)
    is about a page of code.

    Also, you must work in a purely functional language
    in which impure functions are /inexpressible/. That way
    everyone knows at a glance that your results are not
    incorrect on account of some hidden impurity.

    Or else, you must laboriously work everything out with
    Turing Machines: like strip mining for coal with a spoon.

    --
    TXR Programming Language: http://nongnu.org/txr
    Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
    Mastodon: @Kazinator@mstdn.ca

    --- PyGate Linux v1.5.1
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Chris M. Thomasson@3:633/10 to All on Wed Nov 26 23:16:52 2025
    On 11/26/2025 11:06 PM, Kaz Kylheku wrote:
    On 2025-11-27, olcott <polcott333@gmail.com> wrote:
    On 11/26/2025 10:48 PM, Mike Terry wrote:
    On 27/11/2025 04:19, Kaz Kylheku wrote:
    On 2025-11-27, olcott <polcott333@gmail.com> wrote:
    The chief editor of one of the most prestigious
    computer science journals exchanged about 15
    emails with me. The bottom line was that he
    could not understand the x86 language well enough.

    LOL; the obvious interpretation of that is "I will say anything
    for you to stop e-mailing me, you sick crank".


    Or... the chief editor really was ignorant of the x86 instruction set!
    Yes, you'd think that someone in his role would have an idea about how
    processors work (executing instructions, and all that stuff) and have
    some familiarity with x86, but apparently not!

    But don't worry - PO is in the process of making a C-interpreter version >>> of his argument.ÿ Then the editor will have no problem understanding
    PO's argument - you just wait and see!

    Or will he?ÿ If the chief editor is an ignorant dumbo

    Then he wouldn't have been the chief editor of
    one of the most prestigious computer science
    journals that exist.

    who's baffled by
    x86, who's to say he won't be equally ignorant of "C"?ÿ In fact, I'll
    bet that's how it will turn out when PO submits is new revised paper.
    [From PO's perspective at least.]ÿ Hehe.


    The key thing about C is that it is simple
    enough that cheaters look ridiculous.

    You will never be taken seriously if you use languages that are
    completely out of favor in CS academia for doing research in this kind
    of topic.

    You need a language in which a meta-circular interpreter
    (interpreter for that language written in that langauge)
    is about a page of code.

    Also, you must work in a purely functional language
    in which impure functions are /inexpressible/. That way
    everyone knows at a glance that your results are not
    incorrect on account of some hidden impurity.

    Or else, you must laboriously work everything out with
    Turing Machines: like strip mining for coal with a spoon.


    Mabey his might be like this guy that drilled a hole in his head. PO
    says I shall try to halt:

    (Pi (12/12) Movie CLIP - Max Drills His Head (1998) HD)

    https://youtu.be/XGZ0K5Rpacw

    --- PyGate Linux v1.5.1
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Jan van den Broek@3:633/10 to All on Thu Nov 27 07:45:15 2025
    [F'up-To set]

    2025-11-27, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> schrieb:

    [Schnipp]

    Mabey his might be like this guy that drilled a hole in his head. PO
    says I shall try to halt:

    Bart Huges

    https://nl.wikipedia.org/wiki/Bart_Huges

    --
    Jan v/d Broek balglaas@dds.nl

    "Ich kenne das Leben, ich bin im Kino gewesen."

    --- PyGate Linux v1.5.1
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From olcott@3:633/10 to All on Thu Nov 27 09:08:02 2025
    On 11/27/2025 1:06 AM, Kaz Kylheku wrote:
    On 2025-11-27, olcott <polcott333@gmail.com> wrote:
    On 11/26/2025 10:48 PM, Mike Terry wrote:
    On 27/11/2025 04:19, Kaz Kylheku wrote:
    On 2025-11-27, olcott <polcott333@gmail.com> wrote:
    The chief editor of one of the most prestigious
    computer science journals exchanged about 15
    emails with me. The bottom line was that he
    could not understand the x86 language well enough.

    LOL; the obvious interpretation of that is "I will say anything
    for you to stop e-mailing me, you sick crank".


    Or... the chief editor really was ignorant of the x86 instruction set!
    Yes, you'd think that someone in his role would have an idea about how
    processors work (executing instructions, and all that stuff) and have
    some familiarity with x86, but apparently not!

    But don't worry - PO is in the process of making a C-interpreter version >>> of his argument.ÿ Then the editor will have no problem understanding
    PO's argument - you just wait and see!

    Or will he?ÿ If the chief editor is an ignorant dumbo

    Then he wouldn't have been the chief editor of
    one of the most prestigious computer science
    journals that exist.

    who's baffled by
    x86, who's to say he won't be equally ignorant of "C"?ÿ In fact, I'll
    bet that's how it will turn out when PO submits is new revised paper.
    [From PO's perspective at least.]ÿ Hehe.


    The key thing about C is that it is simple
    enough that cheaters look ridiculous.

    You will never be taken seriously if you use languages that are
    completely out of favor in CS academia for doing research in this kind
    of topic.


    It is only by making every slight nuance of the
    halting problem concrete thus never abstracting
    away key details that its error can be directly seen.

    A C interpreter version is my next level.

    You need a language in which a meta-circular interpreter
    (interpreter for that language written in that langauge)
    is about a page of code.

    Also, you must work in a purely functional language
    in which impure functions are /inexpressible/. That way
    everyone knows at a glance that your results are not
    incorrect on account of some hidden impurity.

    Or else, you must laboriously work everything out with
    Turing Machines: like strip mining for coal with a spoon.


    *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

    *Keep repeating unless aborted*
    (a) ? copies its input ???
    (b) ? invokes embedded_H ??? ???
    (c) embedded_H simulates ??? ???

    Original Linz Turing Machine H applied to ???
    H.q0 ??? ??? ?* H.qy // accept state
    H.q0 ??? ??? ?* H.qn // reject state

    I could directly implement an interpreter for the
    above code at the high level of the Linz templates.

    --
    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.

    --- PyGate Linux v1.5.1
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Richard Damon@3:633/10 to All on Thu Nov 27 10:38:45 2025
    On 11/27/25 10:08 AM, olcott wrote:
    On 11/27/2025 1:06 AM, Kaz Kylheku wrote:
    On 2025-11-27, olcott <polcott333@gmail.com> wrote:
    On 11/26/2025 10:48 PM, Mike Terry wrote:
    On 27/11/2025 04:19, Kaz Kylheku wrote:
    On 2025-11-27, olcott <polcott333@gmail.com> wrote:
    The chief editor of one of the most prestigious
    computer science journals exchanged about 15
    emails with me. The bottom line was that he
    could not understand the x86 language well enough.

    LOL; the obvious interpretation of that is "I will say anything
    for you to stop e-mailing me, you sick crank".


    Or... the chief editor really was ignorant of the x86 instruction set! >>>> Yes, you'd think that someone in his role would have an idea about how >>>> processors work (executing instructions, and all that stuff) and have
    some familiarity with x86, but apparently not!

    But don't worry - PO is in the process of making a C-interpreter
    version
    of his argument.ÿ Then the editor will have no problem understanding
    PO's argument - you just wait and see!

    Or will he?ÿ If the chief editor is an ignorant dumbo

    Then he wouldn't have been the chief editor of
    one of the most prestigious computer science
    journals that exist.

    who's baffled by
    x86, who's to say he won't be equally ignorant of "C"?ÿ In fact, I'll
    bet that's how it will turn out when PO submits is new revised paper.
    [From PO's perspective at least.]ÿ Hehe.


    The key thing about C is that it is simple
    enough that cheaters look ridiculous.

    You will never be taken seriously if you use languages that are
    completely out of favor in CS academia for doing research in this kind
    of topic.


    It is only by making every slight nuance of the
    halting problem concrete thus never abstracting
    away key details that its error can be directly seen.

    A C interpreter version is my next level.

    But C Isn't really a good language for this, as C allows
    non-computational code.

    You seem to think that this core requirement doesn't matter, but it just breaks you arguement, and shows your stupidity.


    You need a language in which a meta-circular interpreter
    (interpreter for that language written in that langauge)
    is about a page of code.

    Also, youÿ must work in a purely functional language
    in which impure functions are /inexpressible/. That way
    everyone knows at a glance that your results are not
    incorrect on account of some hidden impurity.

    Or else, you must laboriously work everything out with
    Turing Machines: like strip mining for coal with a spoon.


    *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

    *Keep repeating unless aborted*

    Which since you H DOES abort, means the loop is stoped and the input is halting.


    (a) ? copies its input ???
    (b) ? invokes embedded_H ??? ???
    (c) embedded_H simulates ??? ???

    Original Linz Turing Machine H applied to ???
    H.q0 ??? ??? ?* H.qy // accept state
    H.q0 ??? ??? ?* H.qn // reject state

    I could directly implement an interpreter for the
    above code at the high level of the Linz templates.


    No you can't, because you don't know what any of it means.

    The problem is H must be a computation, which means it always gives the
    same answer for the same input.

    THus, if H(H^, H^) returns rejection, it ALWAYS returns that rejection,
    even to H^(H^) which means H^(H^) will halt, and thus it is wrong.

    You logic is based on ignoring that fact and just lying.

    The meaning of the input isn't what H wants to think of it, the meaning
    of the input is what the problemed defined it to be. If H can't handle
    that, then H never meet the requirements and the programmer (You) is
    just a liar.

    --- PyGate Linux v1.5.1
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Kaz Kylheku@3:633/10 to All on Thu Nov 27 18:05:08 2025
    On 2025-11-27, olcott <polcott333@gmail.com> wrote:
    On 11/27/2025 1:06 AM, Kaz Kylheku wrote:
    You will never be taken seriously if you use languages that are
    completely out of favor in CS academia for doing research in this kind
    of topic.


    It is only by making every slight nuance of the

    You wouldn't recognize a slight nuance if it blew your leg off
    with a 12 gauge. :)

    halting problem concrete thus never abstracting
    away key details that its error can be directly seen.

    A C interpreter version is my next level.

    It's completely counterproductive to use a language that is full of
    undefined behaviors, and fundamentally imperative, for this kind of
    research. It is an immediate red flag for a crank.

    You need extra validation to produce a convincing argument that
    the C is correct, and that everything is purely functional.

    Using C is a regression compared to the 1973 Incomputability paper from
    Tony Hoare.

    "In this paper we draw on the programming
    language LISP.[7] for writing most of the
    example programs. We have chosen this
    language for the following reasons: 1) it is
    fairly widely known, 2) it is a small and
    simple language, 3) it is easy to represent
    Lisp programs as data (S-expressions) which
    can then be manipulated, 4) it is relatively
    easy to write an interpreter of the language
    in Lisp itself, and 5) it might initially seem
    to be easy to write a program which tells
    whether another program will terminate or
    not."

    Hoare (unsurprisingly) had better ideas than you, in 1973.

    Regarding it beng easy to write a Lisp interpreter in Lisp;
    in fact, John MacCarthy wrote the semantics of Lisp in Lisp,
    on paper, before there was a Lisp interpreter!

    Famously, Steve Russel took this specification and hand-translated every
    Lisp expression to machine code (with calls to the necessary subroutines
    for funtionsl like CONS, CAR, ATOM and whatnot). The result was a
    working Lisp interpreter.

    Supposedly MacCarthy was at first taken aback, insisting that Steve is
    doing something wrong; that the specification is only intended as
    a reference, not to be directly turned to executable code.

    --
    TXR Programming Language: http://nongnu.org/txr
    Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
    Mastodon: @Kazinator@mstdn.ca

    --- PyGate Linux v1.5.1
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)