• Kaz is a damned liar

    From olcott@polcott333@gmail.com to comp.theory,comp.lang.c on Mon Oct 27 19:44:19 2025
    From Newsgroup: comp.lang.c

    On 10/27/2025 7:37 PM, Kaz Kylheku wrote:
    On 2025-10-27, Kaz Kylheku <643-408-1753@kylheku.com> wrote:
    On 2025-10-27, dbush <dbush.mobile@gmail.com> wrote:
    On 10/27/2025 4:48 PM, Kaz Kylheku wrote:
    On 2025-10-27, dbush <dbush.mobile@gmail.com> wrote:
    I am only referring to these fifteen lines

    A straight forward sequence of steps that any
    C programmer can easily determine:

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


    Then you have nothing as this is incomplete and cannot be run.

    When I posted the git repo several days ago, Olcott immediately
    called me dishonest and replied with the above nonsense.

    He has been repeating it ever since.

    Basically a meltdown, of sorts.


    Oh yeah, he's thrashing. He knows he's been beat and doesn't dare look
    at your code, lest he has to admit he wasted the last 21 years.

    But I explained that the code can help you validate that your cheats are
    working. If you want to say that DDD simulated by HHH does not halt, and
    not be lying, you can now test that actual claim. If the simulated DDD
    halts, and you would like it not to, you have something to iterate
    against to get that fixed.

    Every engineer would be happy to have an easy, ready-made way to test
    the property of their system that they want to believe to be true.

    Instead of thank you, we get a childish tantrum.

    Unfortunately, it is not that rosy. The problem is that Olcott has not
    only been claiming that various D's do not terminate when simulated
    by various H's. He's been claiming that the D's do not terminate because
    they never reach the "do the opposite" logic at all.

    For instance, I ran a test on an old Halt.obj pulled from the git
    history, and found that when its simulation of the abandoned DD is
    continued, it soon hits an infinite loop.

    While, for that .obj file, it confirms the claim that the simulated DD doesn't terminate, the problem is that the simulated DD in that
    situation fails to terminate due to getting into the infinite loop,
    which is only possible because the simulated HHH(DD) returned non-zero
    to simulated DD.

    Thus the simulated HHH says, about the doubly-simulated DD, that the doubly-simulated DD halts A bug or cheat has been exposed in the
    machine; it is contradicting itself.

    Olcott knows that continuing the abandoned simulation uncovers
    damning evidence against his contraption, regardless of whether it
    halts or not.


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

    H simulates D
    that calls H(D) to simulate D
    that calls H(D) to simulate D
    that calls H(D) to simulate D
    that calls H(D) to simulate D
    that calls H(D) to simulate D
    until H sees this repeating pattern
    --
    Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
    hits a target no one else can see." Arthur Schopenhauer
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Kaz Kylheku@643-408-1753@kylheku.com to comp.theory,comp.lang.c on Tue Oct 28 00:52:58 2025
    From Newsgroup: comp.lang.c

    On 2025-10-28, olcott <polcott333@gmail.com> wrote:
    On 10/27/2025 7:37 PM, Kaz Kylheku wrote:
    On 2025-10-27, Kaz Kylheku <643-408-1753@kylheku.com> wrote:
    On 2025-10-27, dbush <dbush.mobile@gmail.com> wrote:
    On 10/27/2025 4:48 PM, Kaz Kylheku wrote:
    On 2025-10-27, dbush <dbush.mobile@gmail.com> wrote:
    I am only referring to these fifteen lines

    A straight forward sequence of steps that any
    C programmer can easily determine:

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


    Then you have nothing as this is incomplete and cannot be run.

    When I posted the git repo several days ago, Olcott immediately
    called me dishonest and replied with the above nonsense.

    He has been repeating it ever since.

    Basically a meltdown, of sorts.


    Oh yeah, he's thrashing. He knows he's been beat and doesn't dare look >>>> at your code, lest he has to admit he wasted the last 21 years.

    But I explained that the code can help you validate that your cheats are >>> working. If you want to say that DDD simulated by HHH does not halt, and >>> not be lying, you can now test that actual claim. If the simulated DDD
    halts, and you would like it not to, you have something to iterate
    against to get that fixed.

    Every engineer would be happy to have an easy, ready-made way to test
    the property of their system that they want to believe to be true.

    Instead of thank you, we get a childish tantrum.

    Unfortunately, it is not that rosy. The problem is that Olcott has not
    only been claiming that various D's do not terminate when simulated
    by various H's. He's been claiming that the D's do not terminate because
    they never reach the "do the opposite" logic at all.

    For instance, I ran a test on an old Halt.obj pulled from the git
    history, and found that when its simulation of the abandoned DD is
    continued, it soon hits an infinite loop.

    While, for that .obj file, it confirms the claim that the simulated DD
    doesn't terminate, the problem is that the simulated DD in that
    situation fails to terminate due to getting into the infinite loop,
    which is only possible because the simulated HHH(DD) returned non-zero
    to simulated DD.

    Thus the simulated HHH says, about the doubly-simulated DD, that the
    doubly-simulated DD halts A bug or cheat has been exposed in the
    machine; it is contradicting itself.

    Olcott knows that continuing the abandoned simulation uncovers
    damning evidence against his contraption, regardless of whether it
    halts or not.


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

    H simulates D
    that calls H(D) to simulate D
    that calls H(D) to simulate D
    that calls H(D) to simulate D
    that calls H(D) to simulate D
    that calls H(D) to simulate D
    until H sees this repeating pattern

    Disproof. The current Halt7.obj tests the return value of HHH(DDD),
    which looks like this:

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

    according to Olcott's claim above, this is supposed to result in infinite recursion so the return statement is never reached.

    int main()
    {
    Output("Input_Halts = ", HHH(DDD));
    }

    Yet, the execution trace below shows that DDD can be continued and reaches a halting state. The trace also shows more DDD simulations starting up as a side effect. There is the start of an infinite simulation tower, but the simulations are terminating.

    This result can be obtained with the code from this git repo:

    https://www.kylheku.com/cgit/x86utm/

    Everything is visible to the public to examine and criticize. If the execution trace is a "lie", it can easily be exposed by someone skilled in the art
    (so why would I do that?)

    _DDD()
    [00002172] 55 push ebp
    [00002173] 8bec mov ebp,esp
    [00002175] 6872210000 push 00002172
    [0000217a] e853f4ffff call 000015d2
    [0000217f] 83c404 add esp,+04
    [00002182] 5d pop ebp
    [00002183] c3 ret
    Size in bytes:(0018) [00002183]

    [ ... ]

    Local Halt Decider: Infinite Recursion Detected Simulation Stopped

    [0000219f][00103820][00000000] 83c404 add esp,+04 [000021a2][0010381c][00000000] 50 push eax [000021a3][00103818][00000743] 6843070000 push 00000743 [000021a8][00103818][00000743] e8b5e5ffff call 00000762
    Input_Halts = 0
    [000021ad][00103820][00000000] 83c408 add esp,+08 [000021b0][00103820][00000000] 33c0 xor eax,eax [000021b2][00103824][00000018] 5d pop ebp [000021b3][00103828][00000000] c3 ret
    Number of Instructions Executed(10069) == 150 Pages
    RECK: ---------------
    RECK: simulations for these function still exist:
    RECK: entry == 00002172 (_DDD), code_end == 00002183, slave_state == 00103888, EIP == 00001216
    RECK: entry == 00002172 (_DDD), code_end == 00002183, slave_state == 0014E2B0, EIP == 000015D2
    RECK: ---------------
    RECK: continuing simulation of entry == 00002172 (_DDD), code_end == 00002183, slave_state == 00103888, EIP == 00001216
    New slave_stack at:15e38c

    Begin Local Halt Decider Simulation Execution Trace Stored at:16e394
    RECK: newly executing: entry == 00002172 (_DDD), code_end == 00002183, slave_state == 0015E350, EIP == 00002172
    New slave_stack at:1a8db4
    RECK: newly executing: entry == 00002172 (_DDD), code_end == 00002183, slave_state == 001A8D78, EIP == 00002172
    Local Halt Decider: Infinite Recursion Detected Simulation Stopped

    RECK: simulation of entry == 00002172 (_DDD), code_end == 00002183, slave_state == 00103888, EIP == 00002183 reached code_end!
    RECK: ---------------
    RECK: reckoning completed
    --
    TXR Programming Language: http://nongnu.org/txr
    Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
    Mastodon: @Kazinator@mstdn.ca
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Chris M. Thomasson@chris.m.thomasson.1@gmail.com to comp.theory,comp.lang.c on Mon Oct 27 19:05:44 2025
    From Newsgroup: comp.lang.c

    On 10/27/2025 5:52 PM, Kaz Kylheku wrote:
    [...]

    Kaz, casting pearls before swine. It means you care, but Olcott says you
    are worse than a murderous tyrant.

    Sigh. ;^o

    --- Synchronet 3.21a-Linux NewsLink 1.2