• Re: H(D) as simple as it gets

    From olcott@[email protected] to comp.theory on Fri Oct 31 23:04:00 2025
    From Newsgroup: comp.theory

    On 10/31/2025 10:53 PM, Kaz Kylheku wrote:
    On 2025-11-01, olcott <[email protected]> wrote:
    On 10/31/2025 10:15 PM, Kaz Kylheku wrote:
    On 2025-11-01, olcott <[email protected]> wrote:
    On 10/31/2025 8:28 PM, Kaz Kylheku wrote:
    On 2025-11-01, olcott <[email protected]> wrote:
    HHH simulates DDD then DDD calls HHH(DDD) then what?

    The name HHH is taken for a function which not only simulates,

    Not in this case you are far too much of a liar
    to trust you with more than one tiny detail.

    HHH is UTM.

    Pick a set of names for all your digital offsprings,
    your Dicks and Harrys.

    Document that set of names, and stick with it from then on.

    You have sort of done that; you defined a bunch of them in Halt7.c.

    When-so-ever you use any of the names D, DD, H, HH, H1, HHH, HHH1
    and whatnot, they shall be interpreted as the definitions in
    Halt7.c.

    Not just any old Halt7.c, but this one:

    commit 48b4cbfeb3f486507276a5fc4e9b10875ab24dbf
    Author: plolcott <[email protected]>
    Date: Sat Feb 15 18:44:02 2025 -0600

    Add files via upload

    That file doesn't have a UTM(), so I don't know what that
    is. Is HHH1 a close enouch facsimile to be served as UTM?

    If so, pose the question in terms of HHH1.


    I didn't expect that I would have to dumb it
    down that much for a guy that makes this claim:

    Precisely defining what you mean by every single name like HHH,
    and then sticking to that definition henceforth, is
    an activity which does not whatsoever meet any reaosnable
    definition of "dumbing down".


    On 10/31/2025 7:44 PM, Kaz Kylheku wrote:
    I can write a C interpreter which can interpret itself.

    That can only be that you are a damned liar on
    one of these two claims.

    void D5()
    {
    H5(D5);
    return;
    }

    H5 simulates D5 that calls H5(D5)

    OK, you have chosen different names. that's fine for the present, but do
    you want to commit to these definitions of H5 going forward?

    Anyway, in this thread only, let us supose that H5 is just a simulator;
    it simulates to completion.

    D5 is as above.

    D5 calls H5, which initiates an exhaustive simulation of D5.
    The simulated D5 calls H5 which again initiates a simulation.

    In this scenario, no invocation of any H5 at any simulation
    level returns to its D5.

    Why are we still discussing it? You need to keep better
    track of who agreed with what.

    I and multiple others have already agreed with all this numerous times.


    I can't even tell exactly what you said.
    H5 simulates D5 that calls H5(D5)
    What comes next?
    --
    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@[email protected] to comp.theory on Mon Nov 3 20:50:13 2025
    From Newsgroup: comp.theory

    On 2025-11-01, olcott <[email protected]> wrote:
    On 10/31/2025 7:44 PM, Kaz Kylheku wrote:
    On 2025-11-01, olcott <[email protected]> wrote:
    On 10/31/2025 7:31 PM, Kaz Kylheku wrote:

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


    Let's dumb this down as much as possible.

    HHH simulates DDD then DDD calls HHH(DDD)
    then what? DDD dances the jig and jumps
    straight to its return instruction?

    Do you know C well enough to answer this in C?

    Yes. Well, actually I worked this in C++, but mostly C-like C++.

    DDD in your latest Halt.obj,
    Do you know C well enough to answer this in C?

    I can write a C interpreter which can interpret itself.

    I already have one that does that.

    If you did, you'd be tripping over yourself to produce a URL
    pointing to buildable code that procudes execution traces.

    Now that you've abandoned the x86utm (because just person came along
    and actually engaged with the code, did a little exploring
    and found some wee little issue) you've got fuck all.

    You have no idea how to express a proof; the closest you have come was
    to code something. That turns out to be a fuckery with mutating global execution traces, completely unrelated to the theory of recursive
    functions, which are pure. And even with those mutating static state
    /cheats/, it /still/ doesn't behave like you say it does--event hough it
    easily could! I mean it would be totally /wrong/, but at least D/DD/DDD
    could be non-halting in the simulation levels, like you say.

    You can't even do that: get your cheating little ducks lined up in
    in such a way that from a certain deceptive angle, there is an
    illusion that they are in a row.
    --
    TXR Programming Language: http://nongnu.org/txr
    Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
    Mastodon: @[email protected]
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From olcott@[email protected] to comp.theory on Mon Nov 3 14:54:48 2025
    From Newsgroup: comp.theory

    On 11/3/2025 2:50 PM, Kaz Kylheku wrote:
    On 2025-11-01, olcott <[email protected]> wrote:
    On 10/31/2025 7:44 PM, Kaz Kylheku wrote:
    On 2025-11-01, olcott <[email protected]> wrote:
    On 10/31/2025 7:31 PM, Kaz Kylheku wrote:

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


    Let's dumb this down as much as possible.

    HHH simulates DDD then DDD calls HHH(DDD)
    then what? DDD dances the jig and jumps
    straight to its return instruction?

    Do you know C well enough to answer this in C?

    Yes. Well, actually I worked this in C++, but mostly C-like C++.

    DDD in your latest Halt.obj,
    Do you know C well enough to answer this in C?

    I can write a C interpreter which can interpret itself.

    I already have one that does that.

    If you did, you'd be tripping over yourself to produce a URL
    pointing to buildable code that procudes execution traces.

    Now that you've abandoned the x86utm (because just person came along
    and actually engaged with the code, did a little exploring
    and found some wee little issue) you've got fuck all.

    You have no idea how to express a proof; the closest you have come was
    to code something. That turns out to be a fuckery with mutating global execution traces, completely unrelated to the theory of recursive
    functions, which are pure. And even with those mutating static state /cheats/, it /still/ doesn't behave like you say it does--event hough it easily could! I mean it would be totally /wrong/, but at least D/DD/DDD
    could be non-halting in the simulation levels, like you say.

    You can't even do that: get your cheating little ducks lined up in
    in such a way that from a certain deceptive angle, there is an
    illusion that they are in a row.


    I am only replying to one post now:
    [Addressing duffer-speak]

    All other replies will be ignored until I
    get an actual honest dialogue on that post.

    Two people that never once said anything
    beneficial have already been *plonked*
    --
    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@[email protected] to comp.theory on Mon Nov 3 21:22:36 2025
    From Newsgroup: comp.theory

    On 2025-11-03, olcott <[email protected]> wrote:
    Two people that never once said anything
    beneficial have already been *plonked*

    Is there anything you say that is not bullshit?

    Early Last week you plonked someone only to reply to them again less than 24 hours later, far exceeding a prediction that you would do this before Halloween. A prediction that was posted, and could have served you as a reminder to refraing from doing that.
    --
    TXR Programming Language: http://nongnu.org/txr
    Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
    Mastodon: @[email protected]
    --- Synchronet 3.21a-Linux NewsLink 1.2