• What. A. Slog.

    From vallor@21:1/5 to All on Wed May 14 07:11:24 2025
    Spent a couple of hours reading back the last few days of posts. Huboy,
    what a train wreck. (But like a train wreck, it's hard to look
    away, which might explain how this has been going on for 20(?) years.)

    I want to thank both Richard's, wij, dbush, Mike, Keith, Fred,
    Mikko, and anybody else I've forgotten for trying to explain to
    Mr. Olcott and Mr. Flibble how you all see their claims. I wanted to
    point out three things:

    a) Mr. Olcott claims his HHH simulator detects an non-terminating
    input and halts. But others (I forget who) report that -- due
    to a bug -- D would actually terminate on its own. His HHH
    simulator therefore gives the wrong answer.

    b) Mr. Olcott appears to agree with Turing at this point, but may
    be unwilling to abandon the work he's spent so much time on.

    c) (I am not a doctor.) After seeing Mr. Olcott's representations
    of Professor Sipser's words, as well as the way he edits his posts,
    as well as the way he ignores clear refutation, my personal,
    non-professional, opinion is that he's more deluded than
    outright dishonest. Hopefully he can avoid the latter in the future.

    Finally, I agree with what others have posted: this stuff doesn't belong
    in comp.lang.c. Mr. Olcott: you actually have a few experts _and_
    authorities in the C language reading you in this group. Perhaps
    you should follow their suggestions? (Since the description of your
    algorithms are expressed in C, you might want to concentrate on that,
    rather than the compilers assembler language output.)

    --
    -v

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Terry@21:1/5 to vallor on Wed May 14 18:50:44 2025
    On 14/05/2025 08:11, vallor wrote:
    Spent a couple of hours reading back the last few days of posts. Huboy,
    what a train wreck. (But like a train wreck, it's hard to look
    away, which might explain how this has been going on for 20(?) years.)

    I want to thank both Richard's, wij, dbush, Mike, Keith, Fred,
    Mikko, and anybody else I've forgotten for trying to explain to
    Mr. Olcott and Mr. Flibble how you all see their claims. I wanted to
    point out three things:

    a) Mr. Olcott claims his HHH simulator detects an non-terminating
    input and halts. But others (I forget who) report that -- due
    to a bug -- D would actually terminate on its own. His HHH
    simulator therefore gives the wrong answer.

    Not really due to a bug. D actually /does/ terminate on its own, and that's a consequence of PO's
    intended design. (Yes, there are bugs, but D's coding is what PO intended.)


    b) Mr. Olcott appears to agree with Turing at this point, but may
    be unwilling to abandon the work he's spent so much time on.

    c) (I am not a doctor.) After seeing Mr. Olcott's representations
    of Professor Sipser's words, as well as the way he edits his posts,
    as well as the way he ignores clear refutation, my personal, non-professional, opinion is that he's more deluded than
    outright dishonest. Hopefully he can avoid the latter in the future.

    I agree, although he is not completely beyond the odd lie from time to time.

    [Like you, I'm not a doctor either. My ideas below just seem logical to me...]

    I have long put forward my theory that PO is "neurally divergent" or whatever the modern term should
    be: his brain wiring renders him incapable of proper handling of abstract concepts, so naturally he
    cannot follow academic texts, understand their definitions or even their basic concepts, which are
    all "abstract". Also the idea of "proof" or even "logical reasoning" is not something his brain
    registers - yes, he says he is presenting proofs and so on, but he doesn't really know what that
    would entail! He's only saying it because he at least understands that that is what he must do in
    order to "win the argument".

    I don't say any of this to insult PO. It's the conclusion I reached when I looked at the nature of
    PO's mistakes that he makes over and over. Obviously he doesn't "get" basic concepts like TM,
    Halting, function, number, truth, ...whatever, but the clue for me is in what he does instead. He
    encounters the words, and in his head replaces them with non-abstract "concrete/mechanical" notions
    that do not properly reflect the meaning other people pick up. So we have

    - TM --> C progam running on some physical/logical machine (like his x86utm execution environment)
    - function (mathematical) --> C function executing a sequence of steps
    - truth --> provable (proofs have a series of steps that can be mechanically verified)
    - halting --> some simulation by another piece of code reaching its end
    - pgm spec. --> description of the program steps a C function actually performs
    ...
    and so on. In each case, an abstract notion being blanked over, and in his head replaced with
    something more concrete ("procedural"), but missing the essence of the original concept.

    And his "proofs" upon examination are seen to be not "logical reasoning" at all - he will make a
    series of claims that he thinks are true, but they do not actually follow from each other. I don't
    doubt that PO /thinks/ that's what proofs are, because when he encounters others proving things he
    is literally blind to the "logical reasoning" aspect, and just sees somebody telling others what
    they believe is true. I'm sure he thinks the reason that people accept (say) the HP is because some
    "expert" said it was the case, and the expert had been previously granted "reputation" which means
    he has to be taken seriously... And also they use lots of strange symbols and notations, so that
    must be important too, if you want your proof to be accepted!

    So given that he doesn't believe what he believes due to logical reasoning, what is left?
    Intuition. All PO's "refutations" of famous proofs/results are just his first intuition when
    encountering a subject, just as children have first intuitions when they are introduced to new
    ideas. But children grow, they develop and learn to study, reason logically, and can /learn/ that
    first intuitions are sometimes false. PO simply has no basis on which he can move on from his first
    intuitions.

    All the above is really just to say that trying to convince PO that he is wrong by using "logical
    reasoning" is a complete waste of time. My thought was that what he needed was /concrete
    demonstrations/ to convince him, like um, like an actual trace of his D running and returning! But
    PO has that and he just doubles down with more and more contorted explanations for why his first
    intuition was right all along!


    Mike.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Terry@21:1/5 to Mike Terry on Wed May 14 20:06:08 2025
    On 14/05/2025 18:50, Mike Terry wrote:
    On 14/05/2025 08:11, vallor wrote:
    Spent a couple of hours reading back the last few days of posts.� Huboy,
    what a train wreck.� (But like a train wreck, it's hard to look
    away, which might explain how this has been going on for 20(?) years.)

    I want to thank both Richard's, wij, dbush, Mike, Keith, Fred,
    Mikko, and anybody else I've forgotten for trying to explain to
    Mr. Olcott and Mr. Flibble how you all see their claims.� I wanted to
    point out three things:

    a) Mr. Olcott claims his HHH simulator detects an non-terminating
    input and halts.� But others (I forget who) report that -- due
    to a bug -- D would actually terminate on its own.� His HHH
    simulator therefore gives the wrong answer.

    Not really due to a bug.� D actually /does/ terminate on its own, and that's a consequence of PO's
    intended design.� (Yes, there are bugs, but D's coding is what PO intended.)

    Hmm, I thought some more about this. What's considered a bug (rather than e.g. a design error) is
    entirely dependent on the program's specification. It seems perfectly reasonable to say the spec.
    for HHH is to decide whether the computation represented by its input halts. That's the HP
    specification, and PO is discussing halt deciders (or perhaps a "partial halt decider" but the spec
    covering input DD will be the same).

    Accepting that specification, PO's HHH deviates from spec. when given input DD, so that can be filed
    under "bug". The source of the misbehaviour is not the simulation code, but rather one of the
    specific tests HHH applies for non-halting, viz PO's "infinite recursive emulation" test. That test
    is unsound, so we've found the bug! The problem is there's no alternative test it can be changed to
    in order to fix the bug. And it is the test which PO thought up many years ago, and probably sent
    him down the whole HP proof refutation path...

    If this test were simply deleted from HHH to give a new HHH2, then HHH2 processing HHH2's
    corresponding new DD2 would never return, but that is also a violation of the HP spec, so there must
    still be some bug in the new HHH2, right? PO might reason that to fix the "non-halting" bug he HAS
    TO introduce his unsound non-halting test (or similar), AND SO THE NON-HALTING TEST IS CORRECT.
    That's nonsense of course and PO has been told.

    We might say "HHH2 never halts, due to a bug", and that seems technically correct as above, but then
    like the original HHH "bug" there's still no conceivable fix for it.

    In the end, the HP spec cannot logically be satisfied (as shown by Linz proof), so /any/ claim to
    meet that spec is sure to "contain a bug". I'm not sure whether that's a good use for the term "bug"...


    Mike.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Wed May 14 21:37:35 2025
    On 5/14/25 10:48 AM, olcott wrote:
    On 5/14/2025 2:11 AM, vallor wrote:
    Spent a couple of hours reading back the last few days of posts.  Huboy,
    what a train wreck.  (But like a train wreck, it's hard to look
    away, which might explain how this has been going on for 20(?) years.)

    I want to thank both Richard's, wij, dbush, Mike, Keith, Fred,
    Mikko, and anybody else I've forgotten for trying to explain to
    Mr. Olcott and Mr. Flibble how you all see their claims.  I wanted to
    point out three things:

    a) Mr. Olcott claims his HHH simulator detects an non-terminating
    input and halts.  But others (I forget who) report that -- due
    to a bug -- D would actually terminate on its own.  His HHH
    simulator therefore gives the wrong answer.

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

    That is counter-factual. DDD correctly simulated by HHH
    *would never stop running unless aborted*


    No, it is counter-factual to say that HHH correctly simulated DDD.

    After all, by your stipulations, the "input DDD" is JUST that code, and
    doesn't include the HHH that it calls, and therefore you CAN'T simulate
    "DDD" into HHH, but you must.


    b) Mr. Olcott appears to agree with Turing at this point, but may
    be unwilling to abandon the work he's spent so much time on.

    c) (I am not a doctor.)  After seeing Mr. Olcott's representations
    of Professor Sipser's words, as well as the way he edits his posts,
    as well as the way he ignores clear refutation, my personal,
    non-professional, opinion is that he's more deluded than
    outright dishonest.  Hopefully he can avoid the latter in the future.


    It turns out that rhetoric does not really count as rebuttal.
    Neither does changing my words and rebutting these changed words.

    Finally, I agree with what others have posted:  this stuff doesn't belong >> in comp.lang.c.  Mr. Olcott:  you actually have a few experts _and_
    authorities in the C language reading you in this group.

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

    All of those "experts" say that DDD correctly
    simulated by HHH will reach its "return" statement.
    Any novice C programmer can see that this is not true.

    Yes, when you complete DDD with the HHH that is in memory when your HHH
    that you claim is giving the right answer is in memory, and which
    doesn't even correcctly emulate that DDD/HHH combination, since it gives
    up, when correctly simulated will go from DDD into HHH that will
    sijmulate its input (plus that HHH added) for a while, then abort and
    return to DDD which will then return.

    Your problem is you lie to yourself that you can change what is in the
    memory, and what "DDD" is. Choose:

    1) It is just the code of the C function, and doesn't include anything
    outside, in which case it just isn't a program, and a correct sumulation
    of that DDD can't look elsewhere, or it isn't actually emulating DDD.

    2) It is your code for the C funciton, and it includes the contents of
    that it references, in which case that memory IS part of the input, and
    thus you can't change it to make you hypothetical HHH without changing
    the input, and thus you argument is just based on lies.

    3) The memory it references is just included as part of the system, at
    which point it just need to be fully defined, and can't change. Thus you
    need to decide WHICH HHH you are actually talking about. It seem you
    need it to be the HHH that simulatates until it THINKS it has proven
    that it won't be able to simulate it, and aborts. The problem is it then
    needs to also consider that this is also the HHH that the DDD being
    simulated calls, and thus HHH needs to include that behavior in its
    analysis of DDD, and if HHH thinks it should abort, it needs to also
    consider that the HHH it is simulating will do so too, something you
    negect to do.



     Perhaps
    you should follow their suggestions?  (Since the description of your
    algorithms are expressed in C, you might want to concentrate on that,
    rather than the compilers assembler language output.)




    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mikko@21:1/5 to vallor on Thu May 15 11:22:39 2025
    On 2025-05-14 07:11:24 +0000, vallor said:

    c) (I am not a doctor.) After seeing Mr. Olcott's representations
    of Professor Sipser's words, as well as the way he edits his posts,
    as well as the way he ignores clear refutation, my personal, non-professional, opinion is that he's more deluded than
    outright dishonest. Hopefully he can avoid the latter in the future.

    As far as I have seen, most people only as honest as is possible with
    a small effort. They havn't even studied mathematics, physics, or
    religion enough to know what it means to be really honest. I don't
    think the level of Olcott's honesty is far from the level of an average
    person although it is from the level expected in comp.thoery or any
    sci group.

    Finally, I agree with what others have posted: this stuff doesn't belong
    in comp.lang.c. Mr. Olcott: you actually have a few experts _and_ authorities in the C language reading you in this group. Perhaps
    you should follow their suggestions? (Since the description of your algorithms are expressed in C, you might want to concentrate on that,
    rather than the compilers assembler language output.)

    Apparently he foud out that whatever he was looking for in comp.lang.c
    is not there.

    --
    Mikko

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)