• What it would take...

    From Richard Heathfield@21:1/5 to All on Sat May 10 02:11:35 2025
    The HHH code doesn't exactly invite confidence in its author, and
    his theory is all over the place, but a thought experiment
    suggests itself.

    If we were not all wasting our time bickering with a career
    bickerer... if we were to really /really/ try, could we patch up
    his case and send him on to his Turing Award? And if so, how?

    ISTR that there is suspected to be a theoretical window for him,
    so I suppose what I'm asking is what sort of boathook we would
    need to poke that window a little wider.

    Can he even get there from here? Evidence would suggest that
    simulation is a dead end unless he can find a way to get the
    simulated program to include its own simulation in its behaviour,
    which he has not yet managed to do - but /is/ there a way?

    Or could he abandon simulation completely and instead write a TM
    parser that builds an AST and walks it looking for evidence of
    terminating or looping? If he could, would that turn the trick?

    Or do we have a latter day Cantor waiting in the wings to close
    the window once and for all?

    Is there, in short, any way of putting out this un-halting flame
    war and turning this group to better use?

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to Richard Heathfield on Fri May 9 22:18:13 2025
    On 5/9/25 9:11 PM, Richard Heathfield wrote:
    The HHH code doesn't exactly invite confidence in its author, and his
    theory is all over the place, but a thought experiment suggests itself.

    If we were not all wasting our time bickering with a career bickerer...
    if we were to really /really/ try, could we patch up his case and send
    him on to his Turing Award? And if so, how?

    ISTR that there is suspected to be a theoretical window for him, so I
    suppose what I'm asking is what sort of boathook we would need to poke
    that window a little wider.

    Can he even get there from here? Evidence would suggest that simulation
    is a dead end unless he can find a way to get the simulated program to include its own simulation in its behaviour, which he has not yet
    managed to do - but /is/ there a way?

    Or could he abandon simulation completely and instead write a TM parser
    that builds an AST and walks it looking for evidence of terminating or looping? If he could, would that turn the trick?

    Or do we have a latter day Cantor waiting in the wings to close the
    window once and for all?

    Is there, in short, any way of putting out this un-halting flame war and turning this group to better use?


    If he was willing to include the code for HHH in the input representing
    DDD, then HHH would be able to atempt to correctly emulate this input.

    There have been methods put forward, that given an acceptace of the detectability of DDD calling HHH, which can only be done it seems if we
    make the system non-turing complete by saying that the input program and
    the decider are put into the same memory space, and we are not allowed
    to "copy" an algorithm to make a new copy, but only call the origianal
    version so HHH can detect the recursion by reference to that address
    that some versions of programs that do this "recursive simulation" can
    be correctly decider (but not all, like the pathological version).

    In this method, the Decider detecting the recursion, tries emulating the
    code in two parrallel branches based on both possible answers, and if
    one branch matches the behavior of the answer, it can return that answ3er.

    Thus, inputs like DDD() that always halt on the return of HHH(DDD) will
    be correctly determined to be halting, and a varient that just goes into
    an infinite loop can be such detected by well know procedures as
    non-halting.

    The pathological DD() is detected as pathological, and we can perhaps
    extend the definition to allow it to respiond with an "I give up, I
    don't know the answer" response, but such an extention explicitly does
    NOT meet the requirements, but is better than not answering or giving a
    wrong answer.

    The problem is this result doesn't meet Peter's Goal, as it isn't really
    the Halting Problem that he has his major problem with, but the fact
    that Turings Proof became the basis for a number of broader proofs of incompleteness and undeciability that fills formal logic.

    This is what he can't handle, and this is because he just doesn't really understand how all of the works because his mental models of logic is
    just way to small and simple.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mr Flibble@21:1/5 to Richard Damon on Sat May 10 04:04:55 2025
    On Fri, 09 May 2025 22:18:13 -0400, Richard Damon wrote:

    On 5/9/25 9:11 PM, Richard Heathfield wrote:
    The HHH code doesn't exactly invite confidence in its author, and his
    theory is all over the place, but a thought experiment suggests itself.

    If we were not all wasting our time bickering with a career bickerer...
    if we were to really /really/ try, could we patch up his case and send
    him on to his Turing Award? And if so, how?

    ISTR that there is suspected to be a theoretical window for him, so I
    suppose what I'm asking is what sort of boathook we would need to poke
    that window a little wider.

    Can he even get there from here? Evidence would suggest that simulation
    is a dead end unless he can find a way to get the simulated program to
    include its own simulation in its behaviour, which he has not yet
    managed to do - but /is/ there a way?

    Or could he abandon simulation completely and instead write a TM parser
    that builds an AST and walks it looking for evidence of terminating or
    looping? If he could, would that turn the trick?

    Or do we have a latter day Cantor waiting in the wings to close the
    window once and for all?

    Is there, in short, any way of putting out this un-halting flame war
    and turning this group to better use?


    If he was willing to include the code for HHH in the input representing
    DDD, then HHH would be able to atempt to correctly emulate this input.

    There have been methods put forward, that given an acceptace of the detectability of DDD calling HHH, which can only be done it seems if we
    make the system non-turing complete by saying that the input program and
    the decider are put into the same memory space, and we are not allowed
    to "copy" an algorithm to make a new copy, but only call the origianal version so HHH can detect the recursion by reference to that address
    that some versions of programs that do this "recursive simulation" can
    be correctly decider (but not all, like the pathological version).

    In this method, the Decider detecting the recursion, tries emulating the
    code in two parrallel branches based on both possible answers, and if
    one branch matches the behavior of the answer, it can return that
    answ3er.

    Branching is my idea.

    /Flibble

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to Mr Flibble on Sat May 10 08:50:13 2025
    On 5/10/25 12:04 AM, Mr Flibble wrote:
    On Fri, 09 May 2025 22:18:13 -0400, Richard Damon wrote:

    On 5/9/25 9:11 PM, Richard Heathfield wrote:
    The HHH code doesn't exactly invite confidence in its author, and his
    theory is all over the place, but a thought experiment suggests itself.

    If we were not all wasting our time bickering with a career bickerer...
    if we were to really /really/ try, could we patch up his case and send
    him on to his Turing Award? And if so, how?

    ISTR that there is suspected to be a theoretical window for him, so I
    suppose what I'm asking is what sort of boathook we would need to poke
    that window a little wider.

    Can he even get there from here? Evidence would suggest that simulation
    is a dead end unless he can find a way to get the simulated program to
    include its own simulation in its behaviour, which he has not yet
    managed to do - but /is/ there a way?

    Or could he abandon simulation completely and instead write a TM parser
    that builds an AST and walks it looking for evidence of terminating or
    looping? If he could, would that turn the trick?

    Or do we have a latter day Cantor waiting in the wings to close the
    window once and for all?

    Is there, in short, any way of putting out this un-halting flame war
    and turning this group to better use?


    If he was willing to include the code for HHH in the input representing
    DDD, then HHH would be able to atempt to correctly emulate this input.

    There have been methods put forward, that given an acceptace of the
    detectability of DDD calling HHH, which can only be done it seems if we
    make the system non-turing complete by saying that the input program and
    the decider are put into the same memory space, and we are not allowed
    to "copy" an algorithm to make a new copy, but only call the origianal
    version so HHH can detect the recursion by reference to that address
    that some versions of programs that do this "recursive simulation" can
    be correctly decider (but not all, like the pathological version).

    In this method, the Decider detecting the recursion, tries emulating the
    code in two parrallel branches based on both possible answers, and if
    one branch matches the behavior of the answer, it can return that
    answ3er.

    Branching is my idea.

    /Flibble

    It existed prior.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mr Flibble@21:1/5 to Richard Damon on Sat May 10 14:24:18 2025
    On Sat, 10 May 2025 08:50:13 -0400, Richard Damon wrote:

    On 5/10/25 12:04 AM, Mr Flibble wrote:
    On Fri, 09 May 2025 22:18:13 -0400, Richard Damon wrote:

    On 5/9/25 9:11 PM, Richard Heathfield wrote:
    The HHH code doesn't exactly invite confidence in its author, and his
    theory is all over the place, but a thought experiment suggests
    itself.

    If we were not all wasting our time bickering with a career
    bickerer...
    if we were to really /really/ try, could we patch up his case and
    send him on to his Turing Award? And if so, how?

    ISTR that there is suspected to be a theoretical window for him, so I
    suppose what I'm asking is what sort of boathook we would need to
    poke that window a little wider.

    Can he even get there from here? Evidence would suggest that
    simulation is a dead end unless he can find a way to get the
    simulated program to include its own simulation in its behaviour,
    which he has not yet managed to do - but /is/ there a way?

    Or could he abandon simulation completely and instead write a TM
    parser that builds an AST and walks it looking for evidence of
    terminating or looping? If he could, would that turn the trick?

    Or do we have a latter day Cantor waiting in the wings to close the
    window once and for all?

    Is there, in short, any way of putting out this un-halting flame war
    and turning this group to better use?


    If he was willing to include the code for HHH in the input
    representing DDD, then HHH would be able to atempt to correctly
    emulate this input.

    There have been methods put forward, that given an acceptace of the
    detectability of DDD calling HHH, which can only be done it seems if
    we make the system non-turing complete by saying that the input
    program and the decider are put into the same memory space, and we are
    not allowed to "copy" an algorithm to make a new copy, but only call
    the origianal version so HHH can detect the recursion by reference to
    that address that some versions of programs that do this "recursive
    simulation" can be correctly decider (but not all, like the
    pathological version).

    In this method, the Decider detecting the recursion, tries emulating
    the code in two parrallel branches based on both possible answers, and
    if one branch matches the behavior of the answer, it can return that
    answ3er.

    Branching is my idea.

    /Flibble

    It existed prior.

    Prove it.

    /Flibble

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fred. Zwarts@21:1/5 to All on Sat May 10 17:25:40 2025
    Op 10.mei.2025 om 17:07 schreef olcott:
    On 5/9/2025 9:18 PM, Richard Damon wrote:
    On 5/9/25 9:11 PM, Richard Heathfield wrote:
    The HHH code doesn't exactly invite confidence in its author, and his
    theory is all over the place, but a thought experiment suggests itself.

    If we were not all wasting our time bickering with a career
    bickerer... if we were to really /really/ try, could we patch up his
    case and send him on to his Turing Award? And if so, how?

    ISTR that there is suspected to be a theoretical window for him, so I
    suppose what I'm asking is what sort of boathook we would need to
    poke that window a little wider.

    Can he even get there from here? Evidence would suggest that
    simulation is a dead end unless he can find a way to get the
    simulated program to include its own simulation in its behaviour,
    which he has not yet managed to do - but /is/ there a way?

    Or could he abandon simulation completely and instead write a TM
    parser that builds an AST and walks it looking for evidence of
    terminating or looping? If he could, would that turn the trick?

    Or do we have a latter day Cantor waiting in the wings to close the
    window once and for all?

    Is there, in short, any way of putting out this un-halting flame war
    and turning this group to better use?


    If he was willing to include the code for HHH in the input
    representing DDD, then HHH would be able to atempt to correctly
    emulate this input.


    DDD and HHH have always been in the same memory space.
    DDD is the program under test and HHH is the test program.

    And because DDD calls HHH, HHH (with the conditional abort) is part of
    the input.


    There have been methods put forward, that given an acceptace of the
    detectability of DDD calling HHH, which can only be done it seems if
    we make the system non-turing complete by saying that the input
    program and the decider are put into the same memory space, and we are
    not allowed to "copy" an algorithm to make a new copy, but only call
    the origianal version so HHH can detect the recursion by reference to
    that address that some versions of programs that do this "recursive
    simulation" can be correctly decider (but not all, like the
    pathological version).


    HHH is essentially a UTM thus EVERYTHING is in the memory space
    of its UTM tape.

    Except that HHH has a conditional abort, which makes that it is blind
    for the most important part of the input: the conditional abort. This
    bugs makes that HHH is unable to see the specified behaviour.


    In this method, the Decider detecting the recursion, tries emulating
    the code in two parrallel branches based on both possible answers, and
    if one branch matches the behavior of the answer, it can return that
    answ3er.


    We can emulate a branch as if a conditional expression
    was true and as if it was false. HHH determines the
    behavior of DDD on the basis of what would happen if
    HHH never aborted.

    Which is not the input, because the input specifies a HHH that does
    abort. This change of input makes that HHH computes an incorrect mapping.


    <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
        If simulating halt decider H correctly simulates its
        input D until H correctly determines that its simulated D
        *would never stop running unless aborted* then


    Which is a vacuous statement, because it does not correctly simulate its
    input, but it simulates another input. The input specified a finite
    recursion, so the simulator is wrong when it decides that its simulated
    D would never stop.

    Thus, inputs like DDD() that always halt on the return of HHH(DDD)
    will be correctly determined to be halting, and a varient that just
    goes into an infinite loop can be such detected by well know
    procedures as non- halting.


    When HHH continues to emulate DDD until HHH sees the
    repeating pattern that would prevent DDD from ever
    terminating

    No, because it is only a finite repeating pattern, which would
    terminate, because the simulated HHH aborts.


        H can abort its simulation of D and correctly report that D
        specifies a non-halting sequence of configurations.
    </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>

    A vacuous statement, because the required conditions are not met.


    The pathological DD() is detected as pathological, and we can perhaps
    extend the definition to allow it to respiond with an "I give up, I
    don't know the answer" response, but such an extention explicitly does
    NOT meet the requirements, but is better than not answering or giving
    a wrong answer.

    The problem is this result doesn't meet Peter's Goal, as it isn't
    really the Halting Problem that he has his major problem with, but the
    fact that Turings Proof became the basis for a number of broader
    proofs of incompleteness and undeciability that fills formal logic.

    This is what he can't handle, and this is because he just doesn't
    really understand how all of the works because his mental models of
    logic is just way to small and simple.

    Dodge and weave is all you know.

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

    It is a verified fact that DD correctly emulated
    by any simulating termination analyzer HHH specifies
    a non-terminating sequence of configurations.

    Only if HHH does not abort. If HHH aborts, it returns to DD and DD
    halts. A correct simulation should see that.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to Mr Flibble on Sat May 10 14:44:56 2025
    On 5/10/25 10:24 AM, Mr Flibble wrote:
    On Sat, 10 May 2025 08:50:13 -0400, Richard Damon wrote:

    On 5/10/25 12:04 AM, Mr Flibble wrote:
    On Fri, 09 May 2025 22:18:13 -0400, Richard Damon wrote:

    On 5/9/25 9:11 PM, Richard Heathfield wrote:
    The HHH code doesn't exactly invite confidence in its author, and his >>>>> theory is all over the place, but a thought experiment suggests
    itself.

    If we were not all wasting our time bickering with a career
    bickerer...
    if we were to really /really/ try, could we patch up his case and
    send him on to his Turing Award? And if so, how?

    ISTR that there is suspected to be a theoretical window for him, so I >>>>> suppose what I'm asking is what sort of boathook we would need to
    poke that window a little wider.

    Can he even get there from here? Evidence would suggest that
    simulation is a dead end unless he can find a way to get the
    simulated program to include its own simulation in its behaviour,
    which he has not yet managed to do - but /is/ there a way?

    Or could he abandon simulation completely and instead write a TM
    parser that builds an AST and walks it looking for evidence of
    terminating or looping? If he could, would that turn the trick?

    Or do we have a latter day Cantor waiting in the wings to close the
    window once and for all?

    Is there, in short, any way of putting out this un-halting flame war >>>>> and turning this group to better use?


    If he was willing to include the code for HHH in the input
    representing DDD, then HHH would be able to atempt to correctly
    emulate this input.

    There have been methods put forward, that given an acceptace of the
    detectability of DDD calling HHH, which can only be done it seems if
    we make the system non-turing complete by saying that the input
    program and the decider are put into the same memory space, and we are >>>> not allowed to "copy" an algorithm to make a new copy, but only call
    the origianal version so HHH can detect the recursion by reference to
    that address that some versions of programs that do this "recursive
    simulation" can be correctly decider (but not all, like the
    pathological version).

    In this method, the Decider detecting the recursion, tries emulating
    the code in two parrallel branches based on both possible answers, and >>>> if one branch matches the behavior of the answer, it can return that
    answ3er.

    Branching is my idea.

    /Flibble

    It existed prior.

    Prove it.

    /Flibble

    WHy should I? Do the literature search yourself, that or pay for someone
    to do it.

    I think I may have even commented on the idea before you posted, I would
    need to go back through the archives to be sure, and it isn't worth it.
    I do know I have memories of this form of solution from the past, of
    course the biggest limitation is you need to do something to enable the detection of the self-call.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Sat May 10 15:01:11 2025
    On 5/10/25 11:07 AM, olcott wrote:
    On 5/9/2025 9:18 PM, Richard Damon wrote:
    On 5/9/25 9:11 PM, Richard Heathfield wrote:
    The HHH code doesn't exactly invite confidence in its author, and his
    theory is all over the place, but a thought experiment suggests itself.

    If we were not all wasting our time bickering with a career
    bickerer... if we were to really /really/ try, could we patch up his
    case and send him on to his Turing Award? And if so, how?

    ISTR that there is suspected to be a theoretical window for him, so I
    suppose what I'm asking is what sort of boathook we would need to
    poke that window a little wider.

    Can he even get there from here? Evidence would suggest that
    simulation is a dead end unless he can find a way to get the
    simulated program to include its own simulation in its behaviour,
    which he has not yet managed to do - but /is/ there a way?

    Or could he abandon simulation completely and instead write a TM
    parser that builds an AST and walks it looking for evidence of
    terminating or looping? If he could, would that turn the trick?

    Or do we have a latter day Cantor waiting in the wings to close the
    window once and for all?

    Is there, in short, any way of putting out this un-halting flame war
    and turning this group to better use?


    If he was willing to include the code for HHH in the input
    representing DDD, then HHH would be able to atempt to correctly
    emulate this input.


    DDD and HHH have always been in the same memory space.
    DDD is the program under test and HHH is the test program.

    So?

    I guess you don't understand the requirments of a Pure Function, because
    you are just ignorant of the computer science you want to use.


    There have been methods put forward, that given an acceptace of the
    detectability of DDD calling HHH, which can only be done it seems if
    we make the system non-turing complete by saying that the input
    program and the decider are put into the same memory space, and we are
    not allowed to "copy" an algorithm to make a new copy, but only call
    the origianal version so HHH can detect the recursion by reference to
    that address that some versions of programs that do this "recursive
    simulation" can be correctly decider (but not all, like the
    pathological version).


    HHH is essentially a UTM thus EVERYTHING is in the memory space
    of its UTM tape.

    Nope. Since you DEFINED your input for DDD to be JUST the C function for
    DDD, that is ALL that is on its tape.

    The problem is you can't actually convert your mingled program into two seperate Turing Machines the way you have defined it.

    This is the problem with Von Neumann arcitecture machines and
    computation theory. It is too easy to create code structures that break
    the rules of programs in compuation theory. The whole system will be
    one, but when you try to divide that into sub-systems, you can break the requirements.

    This is the advantage of Turing Machines, by necessity, any Turing
    Machine, or sub-machine meets the requirements of a computation.


    In this method, the Decider detecting the recursion, tries emulating
    the code in two parrallel branches based on both possible answers, and
    if one branch matches the behavior of the answer, it can return that
    answ3er.


    We can emulate a branch as if a conditional expression
    was true and as if it was false. HHH determines the
    behavior of DDD on the basis of what would happen if
    HHH never aborted.

    But it can't, as it doesn't have the code for the HHH that DDD calls
    without breaking the rules of the requirement to be a pure function.


    <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
        If simulating halt decider H correctly simulates its
        input D until H correctly determines that its simulated D
        *would never stop running unless aborted* then

    Right, "simulated D" is the correctly simulated D, as that is the only
    type of simulation, and that is only of the PROGRAM D, which mean it
    contains the code for the H that it uses.

    Since your input for D doesn't include that, you can't even get to here.

    If you add that code for the H, then that will be for the code of the
    actual H that you claim gives the correct answer, and thus the code for
    the H that does abort and return 0, and thus the CORRECT emulation of
    that code (which that H doesn't do) will see that, and thus H never had permission to abort.


    Thus, inputs like DDD() that always halt on the return of HHH(DDD)
    will be correctly determined to be halting, and a varient that just
    goes into an infinite loop can be such detected by well know
    procedures as non- halting.


    When HHH continues to emulate DDD until HHH sees the
    repeating pattern that would prevent DDD from ever
    terminating

    But HHH can't see that without breaking the rule


        H can abort its simulation of D and correctly report that D
        specifies a non-halting sequence of configurations.
    </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>

    Right, but it first needs to PROVE that the corerct emulation of the
    input it was given would not halt. That isn't true since the input, when completed, uses the H that does the abort and return 0, and thus the
    correct simulation will reach the final state.

    To imagine HHH doing this, we need a non-realizable machine where the
    outer HHH sees one contents of the memory for its code (the code that
    doesn't abort) while the emulated HHH still had its original code.

    The only way to actually do this requires making the hypothetical HHH
    move to a new address, and it becomes your HHH1.


    The pathological DD() is detected as pathological, and we can perhaps
    extend the definition to allow it to respiond with an "I give up, I
    don't know the answer" response, but such an extention explicitly does
    NOT meet the requirements, but is better than not answering or giving
    a wrong answer.

    The problem is this result doesn't meet Peter's Goal, as it isn't
    really the Halting Problem that he has his major problem with, but the
    fact that Turings Proof became the basis for a number of broader
    proofs of incompleteness and undeciability that fills formal logic.

    This is what he can't handle, and this is because he just doesn't
    really understand how all of the works because his mental models of
    logic is just way to small and simple.

    Dodge and weave is all you know.

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

    It is a verified fact that DD correctly emulated
    by any simulating termination analyzer HHH specifies
    a non-terminating sequence of configurations.


    No, it has been proved that given your stipulations, no HHH exists that
    can emulate the input past the call to HHH, as that code was not given.

    And when we fix that error, and include that code as part of the input,
    there is no HHH that is a decider that correctly emulates its input.

    Yes, there is a version of HHH as a pure function that does correctly
    emulate its particular input, but that never returns an answer, and
    since every HHH is given a DIFFERENT DD, since now it includes the code
    of the HHH that is calling it, which differs.

    Sorry, you are just proving you are an ignorant liar that doesn't care
    about what is true, as you have chosen to ignore all the errors reported
    in your logic, and thus these errors are now deliberate lies.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Sat May 10 15:02:25 2025
    On 5/10/25 12:37 PM, olcott wrote:
    On 5/10/2025 11:18 AM, wij wrote:
    On Sat, 2025-05-10 at 10:46 -0500, olcott wrote:
    On 5/10/2025 10:35 AM, wij wrote:
    On Sat, 2025-05-10 at 10:07 -0500, olcott wrote:
    On 5/9/2025 9:18 PM, Richard Damon wrote:
    On 5/9/25 9:11 PM, Richard Heathfield wrote:
    The HHH code doesn't exactly invite confidence in its author, and >>>>>>> his
    theory is all over the place, but a thought experiment suggests
    itself.

    If we were not all wasting our time bickering with a career
    bickerer... if we were to really /really/ try, could we patch up his >>>>>>> case and send him on to his Turing Award? And if so, how?

    ISTR that there is suspected to be a theoretical window for him, >>>>>>> so I
    suppose what I'm asking is what sort of boathook we would need to >>>>>>> poke
    that window a little wider.

    Can he even get there from here? Evidence would suggest that
    simulation is a dead end unless he can find a way to get the
    simulated
    program to include its own simulation in its behaviour, which he has >>>>>>> not yet managed to do - but /is/ there a way?

    Or could he abandon simulation completely and instead write a TM >>>>>>> parser that builds an AST and walks it looking for evidence of
    terminating or looping? If he could, would that turn the trick?

    Or do we have a latter day Cantor waiting in the wings to close the >>>>>>> window once and for all?

    Is there, in short, any way of putting out this un-halting flame war >>>>>>> and turning this group to better use?


    If he was willing to include the code for HHH in the input
    representing
    DDD, then HHH would be able to atempt to correctly emulate this
    input.


    DDD and HHH have always been in the same memory space.
    DDD is the program under test and HHH is the test program.

    There have been methods put forward, that given an acceptace of the >>>>>> detectability of DDD calling HHH, which can only be done it seems
    if we
    make the system non-turing complete by saying that the input
    program and
    the decider are put into the same memory space, and we are not
    allowed
    to "copy" an algorithm to make a new copy, but only call the
    origianal
    version so HHH can detect the recursion by reference to that address >>>>>> that some versions of programs that do this "recursive simulation" >>>>>> can
    be correctly decider (but not all, like the pathological version). >>>>>>

    HHH is essentially a UTM thus EVERYTHING is in the memory space
    of its UTM tape.

    In this method, the Decider detecting the recursion, tries
    emulating the
    code in two parrallel branches based on both possible answers, and if >>>>>> one branch matches the behavior of the answer, it can return that
    answ3er.


    We can emulate a branch as if a conditional expression
    was true and as if it was false. HHH determines the
    behavior of DDD on the basis of what would happen if
    HHH never aborted.

    <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>        If simulating halt decider H correctly simulates its
           input D until H correctly determines that its simulated D >>>>>        *would never stop running unless aborted* then

    Thus, inputs like DDD() that always halt on the return of HHH(DDD) >>>>>> will
    be correctly determined to be halting, and a varient that just
    goes into
    an infinite loop can be such detected by well know procedures as non- >>>>>> halting.


    When HHH continues to emulate DDD until HHH sees the
    repeating pattern that would prevent DDD from ever
    terminating

           H can abort its simulation of D and correctly report that D >>>>>        specifies a non-halting sequence of configurations.
    </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>
    The pathological DD() is detected as pathological, and we can perhaps >>>>>> extend the definition to allow it to respiond with an "I give up, I >>>>>> don't know the answer" response, but such an extention explicitly
    does
    NOT meet the requirements, but is better than not answering or
    giving a
    wrong answer.

    The problem is this result doesn't meet Peter's Goal, as it isn't
    really
    the Halting Problem that he has his major problem with, but the fact >>>>>> that Turings Proof became the basis for a number of broader proofs of >>>>>> incompleteness and undeciability that fills formal logic.

    This is what he can't handle, and this is because he just doesn't
    really
    understand how all of the works because his mental models of logic is >>>>>> just way to small and simple.

    Dodge and weave is all you know.

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

    It is a verified fact that DD correctly emulated
    by any simulating termination analyzer HHH specifies
    a non-terminating sequence of configurations.


    Nope.
    POOH is intended to decide whether the input D is "impossible" input
    or not.


    counter-factual.

    Why? I made the conclusion from your reply. If what I concluded is
    'counter-factual',
    then your previous replies are counter-factual.
    Do you deny what you had said?


    For HHH(DD) DD is easy thus not impossible.


    Really? Where is the error in my analysis?

    How does HHH emulate code that is isn't allowed to look at?

    Or, ar you just admitting you are so stupid you don't understand those
    basic rules.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mr Flibble@21:1/5 to Richard Damon on Sat May 10 20:05:20 2025
    On Sat, 10 May 2025 14:44:56 -0400, Richard Damon wrote:

    On 5/10/25 10:24 AM, Mr Flibble wrote:
    On Sat, 10 May 2025 08:50:13 -0400, Richard Damon wrote:

    On 5/10/25 12:04 AM, Mr Flibble wrote:
    On Fri, 09 May 2025 22:18:13 -0400, Richard Damon wrote:

    On 5/9/25 9:11 PM, Richard Heathfield wrote:
    The HHH code doesn't exactly invite confidence in its author, and
    his theory is all over the place, but a thought experiment suggests >>>>>> itself.

    If we were not all wasting our time bickering with a career
    bickerer...
    if we were to really /really/ try, could we patch up his case and
    send him on to his Turing Award? And if so, how?

    ISTR that there is suspected to be a theoretical window for him, so >>>>>> I suppose what I'm asking is what sort of boathook we would need to >>>>>> poke that window a little wider.

    Can he even get there from here? Evidence would suggest that
    simulation is a dead end unless he can find a way to get the
    simulated program to include its own simulation in its behaviour,
    which he has not yet managed to do - but /is/ there a way?

    Or could he abandon simulation completely and instead write a TM
    parser that builds an AST and walks it looking for evidence of
    terminating or looping? If he could, would that turn the trick?

    Or do we have a latter day Cantor waiting in the wings to close the >>>>>> window once and for all?

    Is there, in short, any way of putting out this un-halting flame
    war and turning this group to better use?


    If he was willing to include the code for HHH in the input
    representing DDD, then HHH would be able to atempt to correctly
    emulate this input.

    There have been methods put forward, that given an acceptace of the
    detectability of DDD calling HHH, which can only be done it seems if >>>>> we make the system non-turing complete by saying that the input
    program and the decider are put into the same memory space, and we
    are not allowed to "copy" an algorithm to make a new copy, but only
    call the origianal version so HHH can detect the recursion by
    reference to that address that some versions of programs that do
    this "recursive simulation" can be correctly decider (but not all,
    like the pathological version).

    In this method, the Decider detecting the recursion, tries emulating >>>>> the code in two parrallel branches based on both possible answers,
    and if one branch matches the behavior of the answer, it can return
    that answ3er.

    Branching is my idea.

    /Flibble

    It existed prior.

    Prove it.

    /Flibble

    WHy should I? Do the literature search yourself, that or pay for someone
    to do it.

    I think I may have even commented on the idea before you posted, I would
    need to go back through the archives to be sure, and it isn't worth it.
    I do know I have memories of this form of solution from the past, of
    course the biggest limitation is you need to do something to enable the detection of the self-call.

    So you can't prove it. Fine. The idea is mine and mine alone.

    /Flibble

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mikko@21:1/5 to wij on Sun May 11 12:37:30 2025
    On 2025-05-10 16:18:59 +0000, wij said:

    On Sat, 2025-05-10 at 10:46 -0500, olcott wrote:
    On 5/10/2025 10:35 AM, wij wrote:
    On Sat, 2025-05-10 at 10:07 -0500, olcott wrote:
    On 5/9/2025 9:18 PM, Richard Damon wrote:
    On 5/9/25 9:11 PM, Richard Heathfield wrote:
    The HHH code doesn't exactly invite confidence in its author, and his >>>>>> theory is all over the place, but a thought experiment suggests itself. >>>>>>
    If we were not all wasting our time bickering with a career
    bickerer... if we were to really /really/ try, could we patch up his >>>>>> case and send him on to his Turing Award? And if so, how?

    ISTR that there is suspected to be a theoretical window for him, so I >>>>>> suppose what I'm asking is what sort of boathook we would need to poke >>>>>> that window a little wider.

    Can he even get there from here? Evidence would suggest that
    simulation is a dead end unless he can find a way to get the simulated >>>>>> program to include its own simulation in its behaviour, which he has >>>>>> not yet managed to do - but /is/ there a way?

    Or could he abandon simulation completely and instead write a TM
    parser that builds an AST and walks it looking for evidence of
    terminating or looping? If he could, would that turn the trick?

    Or do we have a latter day Cantor waiting in the wings to close the >>>>>> window once and for all?

    Is there, in short, any way of putting out this un-halting flame war >>>>>> and turning this group to better use?


    If he was willing to include the code for HHH in the input representing >>>>> DDD, then HHH would be able to atempt to correctly emulate this input. >>>>>

    DDD and HHH have always been in the same memory space.
    DDD is the program under test and HHH is the test program.

    There have been methods put forward, that given an acceptace of the
    detectability of DDD calling HHH, which can only be done it seems if we >>>>> make the system non-turing complete by saying that the input program and >>>>> the decider are put into the same memory space, and we are not allowed >>>>> to "copy" an algorithm to make a new copy, but only call the origianal >>>>> version so HHH can detect the recursion by reference to that address >>>>> that some versions of programs that do this "recursive simulation" can >>>>> be correctly decider (but not all, like the pathological version).


    HHH is essentially a UTM thus EVERYTHING is in the memory space
    of its UTM tape.

    In this method, the Decider detecting the recursion, tries emulating the >>>>> code in two parrallel branches based on both possible answers, and if >>>>> one branch matches the behavior of the answer, it can return that answ3er.


    We can emulate a branch as if a conditional expression
    was true and as if it was false. HHH determines the
    behavior of DDD on the basis of what would happen if
    HHH never aborted.

    <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
          If simulating halt decider H correctly simulates its
          input D until H correctly determines that its simulated D
          *would never stop running unless aborted* then

    Thus, inputs like DDD() that always halt on the return of HHH(DDD) will >>>>> be correctly determined to be halting, and a varient that just goes into >>>>> an infinite loop can be such detected by well know procedures as non- >>>>> halting.


    When HHH continues to emulate DDD until HHH sees the
    repeating pattern that would prevent DDD from ever
    terminating

          H can abort its simulation of D and correctly report that D >>>>       specifies a non-halting sequence of configurations.
    </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>
    The pathological DD() is detected as pathological, and we can perhaps >>>>> extend the definition to allow it to respiond with an "I give up, I
    don't know the answer" response, but such an extention explicitly does >>>>> NOT meet the requirements, but is better than not answering or giving a >>>>> wrong answer.

    The problem is this result doesn't meet Peter's Goal, as it isn't really >>>>> the Halting Problem that he has his major problem with, but the fact >>>>> that Turings Proof became the basis for a number of broader proofs of >>>>> incompleteness and undeciability that fills formal logic.

    This is what he can't handle, and this is because he just doesn't really >>>>> understand how all of the works because his mental models of logic is >>>>> just way to small and simple.

    Dodge and weave is all you know.

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

    It is a verified fact that DD correctly emulated
    by any simulating termination analyzer HHH specifies
    a non-terminating sequence of configurations.


    Nope.
    POOH is intended to decide whether the input D is "impossible" input or not.


    counter-factual.

    Why? I made the conclusion from your reply. If what I concluded is 'counter-factual',
    then your previous replies are counter-factual.
    Do you deny what you had said?

    That's exactly what "counter-factual" means: if what Olcott had said were
    true your inference would be true, too; but he doesn't believe his words
    so he calls them and anyting inferred from them counter-factual and
    therefore possibly false in the factual world.

    --
    Mikko

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ben Bacarisse@21:1/5 to Richard Heathfield on Tue May 13 00:58:58 2025
    Richard Heathfield <[email protected]> writes:

    On 12/05/2025 18:21, Ben Bacarisse wrote:
    Richard Heathfield <[email protected]> writes:

    The HHH code doesn't exactly invite confidence in its author, and his theory
    is all over the place, but a thought experiment suggests itself.

    If we were not all wasting our time bickering with a career bickerer... if >>> we were to really /really/ try, could we patch up his case and send him on >>> to his Turing Award? And if so, how?
    Eh?

    Do you know the term 'steelmanning'? https://en.wikipedia.org/wiki/Straw_man#Steelmanning

    Yes. That is, as it happens, how I address cranks. I don't usually
    argue against them but try to get them to say, as clearly and as
    unambiguously as possible, what they are trying to say. After a lot of
    back and forth I got PO to be clear and unambiguous about what he was
    saying. For example, I asked

    | Here's the key question: do you still assert that H(P,P) == false is
    | the "correct" answer even though P(P) halts?

    and PO replied "Yes that is the correct answer even though P(P) halts".

    Ref: Message-ID: <[email protected]>
    Date: Sun, 31 Oct 2021 13:23:29 -0500

    This, to my mind, is the steel man that people should be addressing.
    What is the point in countering anything other than this clear position?

    Similarly, he was clear that false (does not halt) was correct for his
    sketched simulator because of what /would happen/ if the code was
    altered by removing the line that makes the simulation stop.

    The current nonsense avoids the need for this because PO does not show
    the full simulation. Mike Terry "steelmanned" the simulation by showing
    the parts PO hides.

    On the other hand, you are spending a lot of time arguing about his
    knowledge and use of C. Yes, it's awful. He knows very little C and
    the code is crap, but that /is/ a straw man -- it's the simplest part of
    his argument to fix. Someone, for example, you, could rewrite it all
    clearly and neatly so that the real error (declaring false to be correct
    for some halting computations) was even more clear. There is nothing
    unfixable about the simulation.

    ISTR that there is suspected to be a theoretical window for him, so I
    suppose what I'm asking is what sort of boathook we would need to poke that >>> window a little wider.
    What on Earth do you mean? What window?

    Well, you know the history better than I do and I'm not about to trawl through a month's worth of back-messages, so maybe I'm talking nonsense, but I was under the impression that the line he was taking to attack on Linz's argument could conceivably have merit.
    ...
    Mr Olcott seems to have (correctly) spotted a minor flaw in
    the proof published by Dr Linz.

    Maybe I grasped the wrong end of that stick.

    I don't know. There is, indeed, a small error in the notation that is
    easy to fix. I offered to explain the details but you said you had
    paint drying that needed to be watched. As far as I can see, both ends
    of the stick say "easy to fix minor flaw". What end did you grasp?

    ...
    (Rather belatedly, it occurs to me that you might be being sarcastic.

    Moi?!? Perish the thought!

    But no, I just thought that Mr Olcott is obviously not good at presenting
    his case, and it occurred to me that we could probably do a far better
    job. We could fix his code, clean up his reasoning, all that, and see what falls out the bottom.

    As explained, I (and others) have done a lot of that. For me the steel
    man is that, to PO, false is correct from some class of halting
    computations. I assumed you were engaging with him just for the fun of
    it, not that you thought there might be some merit in it.

    Even if it's only ash and clinker.

    False is the correct answer for some halting computations. Is that ash
    and clinker? I don't know, but I am puzzled by why so many posts don't
    address this. (For the record, I refuse to talk to him because of his inexcusable rudeness to me. I can take a lot, but his comments were
    finally beyond the pale.)

    --
    Ben.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Heathfield@21:1/5 to Ben Bacarisse on Tue May 13 03:26:50 2025
    On 13/05/2025 00:58, Ben Bacarisse wrote:
    On the other hand, you are spending a lot of time arguing about his
    knowledge and use of C. Yes, it's awful. He knows very little C and
    the code is crap, but that/is/ a straw man -- it's the simplest part of
    his argument to fix.

    Although it was an attempt to motivate him to improve the code,
    it has become blindingly obvious that he's not interested, which
    is precisely why I am going to stop bothering.

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Terry@21:1/5 to Richard Heathfield on Tue May 13 04:05:50 2025
    On 12/05/2025 19:38, Richard Heathfield wrote:
    On 12/05/2025 18:21, Ben Bacarisse wrote:
    Richard Heathfield <[email protected]> writes:

    The HHH code doesn't exactly invite confidence in its author, and his theory
    is all over the place, but a thought experiment suggests itself.

    If we were not all wasting our time bickering with a career bickerer... if >>> we were to really /really/ try, could we patch up his case and send him on >>> to his Turing Award? And if so, how?

    Eh?

    Do you know the term 'steelmanning'?

    https://en.wikipedia.org/wiki/Straw_man#Steelmanning

    ISTR that there is suspected to be a theoretical window for him, so I
    suppose what I'm asking is what sort of boathook we would need to poke that >>> window a little wider.

    What on Earth do you mean?� What window?

    Well, you know the history better than I do and I'm not about to trawl through a month's worth of
    back-messages, so maybe I'm talking nonsense, but I was under the impression that the line he was
    taking to attack on Linz's argument could conceivably have merit.

    What I imagine has happened here is that you've listened to certain posters and taken what they say
    too uncritically.

    PO often suggests that people who aren't here are supporting him somehow. He likes to reference
    professors or people who have published papers or other comments saying things that he thinks
    support his case, but he is totally incapable of correctly assessing their work and what they're
    saying. In any case that is just an appeal to authority to try to shut down opposition.

    Then there's Mr Flibble and his posts about category errors and all. There are not any category
    errors in the Linz proof and his posts should not suggest that there is any merit in what PO is
    saying. One problem for you I think is that you don't understand the Linz proof sufficiently to
    judge for your self on each post you read.

    I posted background on what PO is doing re. the Linz proof, and I probably said something like "*IF*
    PO successfully delivered a program H which correctly decides its corresponding Linz H^, that would
    be a problem for the Linz proof". But I also made clear that his HHH does /not/ do what is needed.
    Maybe I could have been clearer that it's always been obvious to most posters here that /of course/
    his HHH didn't do what he claimed, because the Linz proof proves that it cannot. Nobody thinks
    there was a remote possibility PO might succeed - people were more curious to see in what manner
    exactly he was going wrong etc...



    Mike.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Heathfield@21:1/5 to Andy Walker on Tue May 13 04:09:12 2025
    On 12/05/2025 23:38, Andy Walker wrote:

    <snip>

    Personally, I kf articles of more than 100 lines and some of
    the most prolific posters, and also don't bother to read any
    article which fails to grab my attention on the first
    screenful [kudos to RichardH for

    Your first screenful ended right there. Now /that/ is what I call
    an attention-grabber!

    If my first screenful is full of 'On date time, subscriber
    wrote', I'll scan it for my own name in case a reply is expected,
    but failing that... <shrug> Life's too short.

    <snip>

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Heathfield@21:1/5 to Mike Terry on Tue May 13 04:37:22 2025
    On 13/05/2025 04:23, Mike Terry wrote:
    Mind you it does seem to have gone mad the last month or so.  It
    seems there are only about 2 or 3 actual variations of what PO is
    saying and all the rest is several thousand repeats by both PO
    and responders...

    But /now and again/ they get interesting. It's always a pleasure
    to stumble across lucid articles by obvious experts, especially
    when they have the patient courtesy to explain the bits that I so
    obviously don't quite grok.

    Special mentions in dispatches go to your good self and to Ben,
    both of whom have shown me far more patience than I had any right
    to expect. You are both a credit to Usenet.

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Terry@21:1/5 to Ben Bacarisse on Tue May 13 04:23:08 2025
    On 13/05/2025 00:58, Ben Bacarisse wrote:
    Richard Heathfield <[email protected]> writes:

    On 12/05/2025 18:21, Ben Bacarisse wrote:
    Richard Heathfield <[email protected]> writes:

    The HHH code doesn't exactly invite confidence in its author, and his theory
    is all over the place, but a thought experiment suggests itself.

    If we were not all wasting our time bickering with a career bickerer... if >>>> we were to really /really/ try, could we patch up his case and send him on >>>> to his Turing Award? And if so, how?
    Eh?

    Do you know the term 'steelmanning'?
    https://en.wikipedia.org/wiki/Straw_man#Steelmanning

    Yes. That is, as it happens, how I address cranks. I don't usually
    argue against them but try to get them to say, as clearly and as unambiguously as possible, what they are trying to say. After a lot of
    back and forth I got PO to be clear and unambiguous about what he was
    saying. For example, I asked

    | Here's the key question: do you still assert that H(P,P) == false is
    | the "correct" answer even though P(P) halts?

    and PO replied "Yes that is the correct answer even though P(P) halts".

    Ref: Message-ID: <[email protected]>
    Date: Sun, 31 Oct 2021 13:23:29 -0500

    This, to my mind, is the steel man that people should be addressing.
    What is the point in countering anything other than this clear position?

    Similarly, he was clear that false (does not halt) was correct for his sketched simulator because of what /would happen/ if the code was
    altered by removing the line that makes the simulation stop.

    The current nonsense avoids the need for this because PO does not show
    the full simulation. Mike Terry "steelmanned" the simulation by showing
    the parts PO hides.

    On the other hand, you are spending a lot of time arguing about his
    knowledge and use of C. Yes, it's awful. He knows very little C and
    the code is crap, but that /is/ a straw man -- it's the simplest part of
    his argument to fix. Someone, for example, you, could rewrite it all
    clearly and neatly so that the real error (declaring false to be correct
    for some halting computations) was even more clear. There is nothing unfixable about the simulation.

    ISTR that there is suspected to be a theoretical window for him, so I
    suppose what I'm asking is what sort of boathook we would need to poke that
    window a little wider.
    What on Earth do you mean? What window?

    Well, you know the history better than I do and I'm not about to trawl
    through a month's worth of back-messages, so maybe I'm talking nonsense, but >> I was under the impression that the line he was taking to attack on Linz's >> argument could conceivably have merit.
    ...
    Mr Olcott seems to have (correctly) spotted a minor flaw in
    the proof published by Dr Linz.

    Maybe I grasped the wrong end of that stick.

    I don't know. There is, indeed, a small error in the notation that is
    easy to fix. I offered to explain the details but you said you had
    paint drying that needed to be watched. As far as I can see, both ends
    of the stick say "easy to fix minor flaw". What end did you grasp?

    ...
    (Rather belatedly, it occurs to me that you might be being sarcastic.

    Moi?!? Perish the thought!

    But no, I just thought that Mr Olcott is obviously not good at presenting
    his case, and it occurred to me that we could probably do a far better
    job. We could fix his code, clean up his reasoning, all that, and see what >> falls out the bottom.

    As explained, I (and others) have done a lot of that. For me the steel
    man is that, to PO, false is correct from some class of halting
    computations. I assumed you were engaging with him just for the fun of
    it, not that you thought there might be some merit in it.

    Even if it's only ash and clinker.

    False is the correct answer for some halting computations. Is that ash
    and clinker? I don't know, but I am puzzled by why so many posts don't address this. (For the record, I refuse to talk to him because of his inexcusable rudeness to me. I can take a lot, but his comments were
    finally beyond the pale.)

    I think it's just that PO has stopped talking about that point, and instead embarked on a multi-year
    project to "prove" his argument tiny point by tiny point. For the last year or so he has been stuck
    on his first step, focussing on whether the /simulation/ of his DD performed by HHH progresses as
    far as DD's return. People just respond on the specific points PO posts about.

    Mind you it does seem to have gone mad the last month or so. It seems there are only about 2 or 3
    actual variations of what PO is saying and all the rest is several thousand repeats by both PO and
    responders...


    Mike.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Heathfield@21:1/5 to Mike Terry on Tue May 13 04:23:21 2025
    On 13/05/2025 04:05, Mike Terry wrote:
    On 12/05/2025 19:38, Richard Heathfield wrote:
    On 12/05/2025 18:21, Ben Bacarisse wrote:
    Richard Heathfield <[email protected]> writes:

    [Can we steelman HHH(DDD)...?]
    <Ben snipped. Sorry, Ben.>

    Well, you know the history better than I do and I'm not about
    to trawl through a month's worth of back-messages, so maybe I'm
    talking nonsense, but I was under the impression that the line
    he was taking to attack on Linz's argument could conceivably
    have merit.

    What I imagine has happened here is that you've listened to
    certain posters and taken what they say too uncritically.

    Maintenant nous sommes getting somewhere.

    PO often suggests that people who aren't here are supporting him
    somehow.  He likes to reference professors or people who have
    published papers or other comments saying things that he thinks
    support his case, but he is totally incapable of correctly
    assessing their work and what they're saying.  In any case that
    is just an appeal to authority to try to shut down opposition.

    Then there's Mr Flibble and his posts about category errors and
    all.  There are not any category errors in the Linz proof and his
    posts should not suggest that there is any merit in what PO is
    saying.  One problem for you I think is that you don't understand
    the Linz proof sufficiently to judge for your self on each post
    you read.

    Undoubtedly the case.

    I posted background on what PO is doing re. the Linz proof, and I
    probably said something like "*IF* PO successfully delivered a
    program H which correctly decides its corresponding Linz H^, that
    would be a problem for the Linz proof".

    Ha! I knew it! That weasel Mike Terry is at the root of all this!

    But I also made clear
    that his HHH does /not/ do what is needed.

    No doubt by then my eyes had glazed over. Next time I'll try to
    stay awake a bit longer.

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Tue May 13 00:16:15 2025
    On 5/12/25 11:38 PM, olcott wrote:
    On 5/12/2025 10:23 PM, Mike Terry wrote:
    On 13/05/2025 00:58, Ben Bacarisse wrote:
    Richard Heathfield <[email protected]> writes:

    On 12/05/2025 18:21, Ben Bacarisse wrote:
    Richard Heathfield <[email protected]> writes:

    The HHH code doesn't exactly invite confidence in its author, and
    his theory
    is all over the place, but a thought experiment suggests itself.

    If we were not all wasting our time bickering with a career
    bickerer... if
    we were to really /really/ try, could we patch up his case and
    send him on
    to his Turing Award? And if so, how?
    Eh?

    Do you know the term 'steelmanning'?
    https://en.wikipedia.org/wiki/Straw_man#Steelmanning

    Yes.  That is, as it happens, how I address cranks.  I don't usually
    argue against them but try to get them to say, as clearly and as
    unambiguously as possible, what they are trying to say.  After a lot of >>> back and forth I got PO to be clear and unambiguous about what he was
    saying.  For example, I asked

    | Here's the key question: do you still assert that H(P,P) == false is
    | the "correct" answer even though P(P) halts?

    and PO replied "Yes that is the correct answer even though P(P) halts".

    Ref: Message-ID: <[email protected]>
          Date: Sun, 31 Oct 2021 13:23:29 -0500

    This, to my mind, is the steel man that people should be addressing.
    What is the point in countering anything other than this clear position? >>>
    Similarly, he was clear that false (does not halt) was correct for his
    sketched simulator because of what /would happen/ if the code was
    altered by removing the line that makes the simulation stop.

    The current nonsense avoids the need for this because PO does not show
    the full simulation.  Mike Terry "steelmanned" the simulation by showing >>> the parts PO hides.

    On the other hand, you are spending a lot of time arguing about his
    knowledge and use of C.  Yes, it's awful.  He knows very little C and
    the code is crap, but that /is/ a straw man -- it's the simplest part of >>> his argument to fix.  Someone, for example, you, could rewrite it all
    clearly and neatly so that the real error (declaring false to be correct >>> for some halting computations) was even more clear.  There is nothing
    unfixable about the simulation.

    ISTR that there is suspected to be a theoretical window for him, so I >>>>>> suppose what I'm asking is what sort of boathook we would need to
    poke that
    window a little wider.
    What on Earth do you mean?  What window?

    Well, you know the history better than I do and I'm not about to trawl >>>> through a month's worth of back-messages, so maybe I'm talking
    nonsense, but
    I was under the impression that the line he was taking to attack on
    Linz's
    argument could conceivably have merit.
    ...
    Mr Olcott seems to have (correctly) spotted a minor flaw in
    the proof published by Dr Linz.

    Maybe I grasped the wrong end of that stick.

    I don't know.  There is, indeed, a small error in the notation that is
    easy to fix.  I offered to explain the details but you said you had
    paint drying that needed to be watched.  As far as I can see, both ends >>> of the stick say "easy to fix minor flaw".  What end did you grasp?

    ...
    (Rather belatedly, it occurs to me that you might be being sarcastic. >>>>
    Moi?!? Perish the thought!

    But no, I just thought that Mr Olcott is obviously not good at
    presenting
    his case, and it occurred to me that we could probably do a far better >>>> job. We could fix his code, clean up his reasoning, all that, and
    see what
    falls out the bottom.

    As explained, I (and others) have done a lot of that.  For me the steel >>> man is that, to PO, false is correct from some class of halting
    computations.  I assumed you were engaging with him just for the fun of >>> it, not that you thought there might be some merit in it.

    Even if it's only ash and clinker.

    False is the correct answer for some halting computations.  Is that ash >>> and clinker?  I don't know, but I am puzzled by why so many posts don't >>> address this.  (For the record, I refuse to talk to him because of his
    inexcusable rudeness to me.  I can take a lot, but his comments were
    finally beyond the pale.)

    I think it's just that PO has stopped talking about that point, and
    instead embarked on a multi-year project to "prove" his argument tiny
    point by tiny point.  For the last year or so he has been stuck on his
    first step, focussing on whether the /simulation/ of his DD performed
    by HHH progresses as far as DD's return.  People just respond on the
    specific points PO posts about.

    Mind you it does seem to have gone mad the last month or so.  It seems
    there are only about 2 or 3 actual variations of what PO is saying and
    all the rest is several thousand repeats by both PO and responders...


    Mike.


    I will continue to make my points endlessly until
    someone chooses not to dodge them. Ben wasted
    fifteen years of my life with his "change the subject"
    rebuttal.

    And, because you don't answer the ERRORS pointed out, just prove your
    total ignorance of what you are talking about.

    Repeating lies doesn't make the error any more true, but just proves the stupidity of the speaker.


    My aim is to continue to make my same points
    so that the people dodging them look increasingly
    foolish and/or dishonest. I keep refining them
    slightly so disagreement is looking more and
    more ridiculous and/or dishonest.


    And thus PROVE that you have no idea of what you are talking about, and
    that you are incapable of learning out it.

    Sorry, you are just proving that you are a pathological idiot.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Tue May 13 00:17:05 2025
    On 5/12/25 11:44 PM, olcott wrote:
    On 5/12/2025 10:41 PM, Richard Heathfield wrote:
    On 13/05/2025 04:38, olcott wrote:
    I will continue to make my points endlessly

    I think that's all we need to know.


    Until people are ashamed for failing to address
    the points that I have been making.


    But we have been addressing them.

    It just seems you are too stupid to understand the points, or just to
    much a liar to be bothered by your errors.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Tue May 13 00:34:35 2025
    On 5/13/25 12:14 AM, olcott wrote:
    On 5/12/2025 10:41 PM, Richard Heathfield wrote:
    On 13/05/2025 04:38, olcott wrote:
    I will continue to make my points endlessly

    I think that's all we need to know.


    My aim is to continue to make my same points
    so that the people dodging them look increasingly
    foolish and/or dishonest. I keep refining them
    slightly so disagreement is looking more and
    more ridiculous and/or dishonest.

    You seems to not know enough to address my
    points yet say that I am wrong about them anyway.


    No, YOU are the one that is looking increasingly foolish.

    After all, you have already admitted that you program and input aren't
    even of the category of items needed for the Halting Problem, but this
    doesn't seem to matter to you.

    That is like complaining that you language tutor program can't feed your
    cat.

    The Halting Problem is about a PROGRAM that can decide on the behavior
    of a PROGRAM (and its input) given to it as a represention, telling for
    *ANY* program if it will halt on that input.

    The Termination Analyser problem that you try to switch to is even
    harder, it is about a PROGRAM that can decide on the behavior of a
    PROGRAM, and ALL POSSIBLE inputs to it, telling if it will halt on all
    of them, in other words decide if the program described by its input is
    a decider.

    Perhaps you get confused by the fact that everyone knows you can't do
    such a thing, and thus are looking to see how close to this they can
    get, to see if their (partial) Halt Decider or Termination Analyser can
    handle a large enough range of possible inputs to do something
    meaningful, What classes of programs can we do good jobs on, and what
    classes of programs are harder. Always answering (even if it is "I can't
    tell") and never giving a wrong answers are good properties, normally
    included as a requirement for a good partial decider.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?B?QW5kcsOpIEcuIElzYWFr?=@21:1/5 to Mike Terry on Mon May 12 22:41:36 2025
    On 2025-05-12 21:23, Mike Terry wrote:

    Mind you it does seem to have gone mad the last month or so.  It seems
    there are only about 2 or 3 actual variations of what PO is saying and
    all the rest is several thousand repeats by both PO and responders...

    Those who insist on responding to Olcott (of which I admit I have
    occasionally been one despite my better intuitions) would be well
    advised to adopt something like the rule of ko (in the game go) which
    prohibits one from returning to the exact same position. Simply
    repeating the same objection after olcott has ignored it is pointless.
    If he didn't get the objection the fiftieth time he's not going to get
    it the fifty-first time either.

    If people adopted this policy most of the threads on this forum would be considerably shorter.

    André

    --
    To email remove 'invalid' & replace 'gm' with well known Google mail
    service.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Heathfield@21:1/5 to olcott on Tue May 13 04:41:17 2025
    On 13/05/2025 04:38, olcott wrote:
    I will continue to make my points endlessly

    I think that's all we need to know.

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mikko@21:1/5 to olcott on Tue May 13 12:49:10 2025
    On 2025-05-13 03:38:41 +0000, olcott said:

    On 5/12/2025 10:23 PM, Mike Terry wrote:
    On 13/05/2025 00:58, Ben Bacarisse wrote:
    Richard Heathfield <[email protected]> writes:

    On 12/05/2025 18:21, Ben Bacarisse wrote:
    Richard Heathfield <[email protected]> writes:

    The HHH code doesn't exactly invite confidence in its author, and his theory
    is all over the place, but a thought experiment suggests itself.

    If we were not all wasting our time bickering with a career bickerer... if
    we were to really /really/ try, could we patch up his case and send him on
    to his Turing Award? And if so, how?
    Eh?

    Do you know the term 'steelmanning'?
    https://en.wikipedia.org/wiki/Straw_man#Steelmanning

    Yes.  That is, as it happens, how I address cranks.  I don't usually
    argue against them but try to get them to say, as clearly and as
    unambiguously as possible, what they are trying to say.  After a lot of >>> back and forth I got PO to be clear and unambiguous about what he was
    saying.  For example, I asked

    | Here's the key question: do you still assert that H(P,P) == false is
    | the "correct" answer even though P(P) halts?

    and PO replied "Yes that is the correct answer even though P(P) halts".

    Ref: Message-ID: <[email protected]>
          Date: Sun, 31 Oct 2021 13:23:29 -0500

    This, to my mind, is the steel man that people should be addressing.
    What is the point in countering anything other than this clear position? >>>
    Similarly, he was clear that false (does not halt) was correct for his
    sketched simulator because of what /would happen/ if the code was
    altered by removing the line that makes the simulation stop.

    The current nonsense avoids the need for this because PO does not show
    the full simulation.  Mike Terry "steelmanned" the simulation by showing >>> the parts PO hides.

    On the other hand, you are spending a lot of time arguing about his
    knowledge and use of C.  Yes, it's awful.  He knows very little C and
    the code is crap, but that /is/ a straw man -- it's the simplest part of >>> his argument to fix.  Someone, for example, you, could rewrite it all
    clearly and neatly so that the real error (declaring false to be correct >>> for some halting computations) was even more clear.  There is nothing
    unfixable about the simulation.

    ISTR that there is suspected to be a theoretical window for him, so I >>>>>> suppose what I'm asking is what sort of boathook we would need to poke that
    window a little wider.
    What on Earth do you mean?  What window?

    Well, you know the history better than I do and I'm not about to trawl >>>> through a month's worth of back-messages, so maybe I'm talking nonsense, but
    I was under the impression that the line he was taking to attack on Linz's >>>> argument could conceivably have merit.
    ...
    Mr Olcott seems to have (correctly) spotted a minor flaw in
    the proof published by Dr Linz.

    Maybe I grasped the wrong end of that stick.

    I don't know.  There is, indeed, a small error in the notation that is
    easy to fix.  I offered to explain the details but you said you had
    paint drying that needed to be watched.  As far as I can see, both ends >>> of the stick say "easy to fix minor flaw".  What end did you grasp?

    ...
    (Rather belatedly, it occurs to me that you might be being sarcastic. >>>>
    Moi?!? Perish the thought!

    But no, I just thought that Mr Olcott is obviously not good at presenting >>>> his case, and it occurred to me that we could probably do a far better >>>> job. We could fix his code, clean up his reasoning, all that, and see what >>>> falls out the bottom.

    As explained, I (and others) have done a lot of that.  For me the steel >>> man is that, to PO, false is correct from some class of halting
    computations.  I assumed you were engaging with him just for the fun of >>> it, not that you thought there might be some merit in it.

    Even if it's only ash and clinker.

    False is the correct answer for some halting computations.  Is that ash >>> and clinker?  I don't know, but I am puzzled by why so many posts don't >>> address this.  (For the record, I refuse to talk to him because of his
    inexcusable rudeness to me.  I can take a lot, but his comments were
    finally beyond the pale.)

    I think it's just that PO has stopped talking about that point, and
    instead embarked on a multi-year project to "prove" his argument tiny
    point by tiny point.  For the last year or so he has been stuck on his
    first step, focussing on whether the /simulation/ of his DD performed
    by HHH progresses as far as DD's return.  People just respond on the
    specific points PO posts about.

    Mind you it does seem to have gone mad the last month or so.  It seems
    there are only about 2 or 3 actual variations of what PO is saying and
    all the rest is several thousand repeats by both PO and responders...


    Mike.


    I will continue to make my points endlessly until
    someone chooses not to dodge them. Ben wasted
    fifteen years of my life with his "change the subject"
    rebuttal.

    No, he didn't. You wasted more than that by your own life with your
    own "change the subject" rebuttal.

    --
    Mikko

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fred. Zwarts@21:1/5 to All on Tue May 13 13:48:55 2025
    Op 12.mei.2025 om 19:29 schreef olcott:
    On 5/9/2025 8:11 PM, Richard Heathfield wrote:
    The HHH code doesn't exactly invite confidence in its author, and his
    theory is all over the place, but a thought experiment suggests itself.

    If we were not all wasting our time bickering with a career
    bickerer... if we were to really /really/ try, could we patch up his
    case and send him on to his Turing Award? And if so, how?

    ISTR that there is suspected to be a theoretical window for him, so I
    suppose what I'm asking is what sort of boathook we would need to poke
    that window a little wider.

    Can he even get there from here? Evidence would suggest that
    simulation is a dead end unless he can find a way to get the simulated
    program to include its own simulation in its behaviour, which he has
    not yet managed to do - but /is/ there a way?

    Or could he abandon simulation completely and instead write a TM
    parser that builds an AST and walks it looking for evidence of
    terminating or looping? If he could, would that turn the trick?

    Or do we have a latter day Cantor waiting in the wings to close the
    window once and for all?

    Is there, in short, any way of putting out this un-halting flame war
    and turning this group to better use?


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

    DD correctly simulated by any pure simulator
    named HHH cannot possibly terminate thus proving

    that the simulation failed and therefore is incorrect, because the end
    is reachable as proven by other simulators, but HHH fails to reach this reachable end.

    that this criteria has

    not

    been met:>
    <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
        If simulating halt decider H correctly simulates its
        input D until H correctly determines that its simulated D
        would never stop running unless aborted then

        H can abort its simulation of D and correctly report that D
        specifies a non-halting sequence of configurations.
    </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>

    This is about a correct simulation. So it does not apply to the above
    incorrect simulation.
    You seem to be very short of memory. Why repeating so many times claims
    that have been proven to be irrelevant?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fred. Zwarts@21:1/5 to All on Tue May 13 13:54:21 2025
    Op 13.mei.2025 om 07:06 schreef olcott:
    On 5/12/2025 11:41 PM, André G. Isaak wrote:
    On 2025-05-12 21:23, Mike Terry wrote:

    Mind you it does seem to have gone mad the last month or so.  It
    seems there are only about 2 or 3 actual variations of what PO is
    saying and all the rest is several thousand repeats by both PO and
    responders...

    Those who insist on responding to Olcott (of which I admit I have
    occasionally been one despite my better intuitions) would be well
    advised to adopt something like the rule of ko (in the game go) which
    prohibits one from returning to the exact same position. Simply
    repeating the same objection after olcott has ignored it is pointless.
    If he didn't get the objection the fiftieth time he's not going to get
    it the fifty-first time either.

    If people adopted this policy most of the threads on this forum would
    be considerably shorter.

    André


    If people would actually address rather than
    dishonestly dodge the key points that I making
    they would see that I am correct.

    If olcott would only stop ignoring everything that disturbs his dreams,
    he would see that his key points have been addresses and refuted many
    times already.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Terry@21:1/5 to Fred. Zwarts on Tue May 13 16:47:23 2025
    On 13/05/2025 12:54, Fred. Zwarts wrote:
    Op 13.mei.2025 om 07:06 schreef olcott:
    On 5/12/2025 11:41 PM, Andr� G. Isaak wrote:
    On 2025-05-12 21:23, Mike Terry wrote:

    Mind you it does seem to have gone mad the last month or so.� It seems there are only about 2 or
    3 actual variations of what PO is saying and all the rest is several thousand repeats by both PO
    and responders...

    Those who insist on responding to Olcott (of which I admit I have occasionally been one despite
    my better intuitions) would be well advised to adopt something like the rule of ko (in the game
    go) which prohibits one from returning to the exact same position. Simply repeating the same
    objection after olcott has ignored it is pointless. If he didn't get the objection the fiftieth
    time he's not going to get it the fifty-first time either.

    If people adopted this policy most of the threads on this forum would be considerably shorter.

    Andr�


    If people would actually address rather than
    dishonestly dodge the key points that I making
    they would see that I am correct.

    If olcott would only stop ignoring everything that disturbs his dreams, he would see that his key
    points have been addresses and refuted many times already.

    We might call that a disturbing ko.

    Mike.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Heathfield@21:1/5 to Mr Flibble on Tue May 13 19:37:45 2025
    On 13/05/2025 19:28, Mr Flibble wrote:
    On Mon, 12 May 2025 23:38:10 +0100, Andy Walker wrote:

    <snip>

    [For all I know, that's how PO already operates and he is not the
    sad misguided attention-seeking person that most here seem to assume,
    but is instead running a vast psychological experiment to see how far he
    can push his LLM before anyone (other than our resident penguin)
    notices.]

    Several of my recent posts (e.g. Flibble's Leap) were AI generated and I don't mind admitting it: AI is a useful tool.

    /Flibble

    Do you wish to be able to mind admitting it: AI is a useful tool?

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mr Flibble@21:1/5 to Richard Heathfield on Tue May 13 18:40:42 2025
    On Tue, 13 May 2025 19:37:45 +0100, Richard Heathfield wrote:

    On 13/05/2025 19:28, Mr Flibble wrote:
    On Mon, 12 May 2025 23:38:10 +0100, Andy Walker wrote:

    <snip>

    [For all I know, that's how PO already operates and he is not the
    sad misguided attention-seeking person that most here seem to assume,
    but is instead running a vast psychological experiment to see how far
    he can push his LLM before anyone (other than our resident penguin)
    notices.]

    Several of my recent posts (e.g. Flibble's Leap) were AI generated and
    I don't mind admitting it: AI is a useful tool.

    /Flibble

    Do you wish to be able to mind admitting it: AI is a useful tool?

    eh? No.

    /Flibble

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mr Flibble@21:1/5 to Andy Walker on Tue May 13 18:28:28 2025
    On Mon, 12 May 2025 23:38:10 +0100, Andy Walker wrote:

    On 12/05/2025 18:21, Ben Bacarisse wrote:
    I have tired to suggest that everyone simply stop replying to PO. He
    does not want to be right, he wants the attention and after a final
    flurry of insulting posts he would probably go elsewhere.

    I too have tried that suggestion. But no, every obsessive poster
    here seems to think that they have a killer argument that will finally persuade Peter that he is wrong. Repeated claims of stupidity, lying,
    and so on does nothing to lower the temperature. You would think that bashing ones head against a brick wall 20+ times/day would eventually
    lead to enlightenment, but no, it seems instead to lead to even greater determination not to be the poster who simply stops.

    Personally, I kf articles of more than 100 lines and some of the
    most prolific posters, and also don't bother to read any article which
    fails to grab my attention on the first screenful [kudos to RichardH for being one of very few posters to snip appropriately]. That, at least,
    makes the group readable. I hope someone will wake me up if there is
    ever any actual progress made. Some hope! Sadly, it seems more likely
    that two or more posters will discover the joys of AI and set their
    computer to auto-reply semi-intelligently to each and every post.

    [For all I know, that's how PO already operates and he is not the
    sad misguided attention-seeking person that most here seem to assume,
    but is instead running a vast psychological experiment to see how far he
    can push his LLM before anyone (other than our resident penguin)
    notices.]

    Several of my recent posts (e.g. Flibble's Leap) were AI generated and I
    don't mind admitting it: AI is a useful tool.

    /Flibble

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Heathfield@21:1/5 to Mr Flibble on Tue May 13 19:47:07 2025
    On 13/05/2025 19:40, Mr Flibble wrote:
    On Tue, 13 May 2025 19:37:45 +0100, Richard Heathfield wrote:

    On 13/05/2025 19:28, Mr Flibble wrote:
    On Mon, 12 May 2025 23:38:10 +0100, Andy Walker wrote:

    <snip>

    [For all I know, that's how PO already operates and he is not the
    sad misguided attention-seeking person that most here seem to assume,
    but is instead running a vast psychological experiment to see how far
    he can push his LLM before anyone (other than our resident penguin)
    notices.]

    Several of my recent posts (e.g. Flibble's Leap) were AI generated and
    I don't mind admitting it: AI is a useful tool.

    /Flibble

    Do you wish to be able to mind admitting it: AI is a useful tool?

    eh? No.


    You are being a bit negative.


    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Heathfield@21:1/5 to Mr Flibble on Tue May 13 20:01:56 2025
    On 13/05/2025 19:53, Mr Flibble wrote:
    On Tue, 13 May 2025 19:47:07 +0100, Richard Heathfield wrote:

    On 13/05/2025 19:40, Mr Flibble wrote:
    On Tue, 13 May 2025 19:37:45 +0100, Richard Heathfield wrote:

    On 13/05/2025 19:28, Mr Flibble wrote:
    On Mon, 12 May 2025 23:38:10 +0100, Andy Walker wrote:

    <snip>

    [For all I know, that's how PO already operates and he is not the >>>>>> sad misguided attention-seeking person that most here seem to
    assume,
    but is instead running a vast psychological experiment to see how
    far he can push his LLM before anyone (other than our resident
    penguin) notices.]

    Several of my recent posts (e.g. Flibble's Leap) were AI generated
    and I don't mind admitting it: AI is a useful tool.

    /Flibble

    Do you wish to be able to mind admitting it: AI is a useful tool?

    eh? No.


    You are being a bit negative.

    Oh. ELIZA bears no resemblance to modern LLM AIs, dear.

    Good spot. But the principle is the same.

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mr Flibble@21:1/5 to Richard Heathfield on Tue May 13 18:53:05 2025
    On Tue, 13 May 2025 19:47:07 +0100, Richard Heathfield wrote:

    On 13/05/2025 19:40, Mr Flibble wrote:
    On Tue, 13 May 2025 19:37:45 +0100, Richard Heathfield wrote:

    On 13/05/2025 19:28, Mr Flibble wrote:
    On Mon, 12 May 2025 23:38:10 +0100, Andy Walker wrote:

    <snip>

    [For all I know, that's how PO already operates and he is not the
    sad misguided attention-seeking person that most here seem to
    assume,
    but is instead running a vast psychological experiment to see how
    far he can push his LLM before anyone (other than our resident
    penguin) notices.]

    Several of my recent posts (e.g. Flibble's Leap) were AI generated
    and I don't mind admitting it: AI is a useful tool.

    /Flibble

    Do you wish to be able to mind admitting it: AI is a useful tool?

    eh? No.


    You are being a bit negative.

    Oh. ELIZA bears no resemblance to modern LLM AIs, dear.

    /Flibble

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mr Flibble@21:1/5 to Richard Heathfield on Tue May 13 19:07:12 2025
    On Tue, 13 May 2025 20:01:56 +0100, Richard Heathfield wrote:

    On 13/05/2025 19:53, Mr Flibble wrote:
    On Tue, 13 May 2025 19:47:07 +0100, Richard Heathfield wrote:

    On 13/05/2025 19:40, Mr Flibble wrote:
    On Tue, 13 May 2025 19:37:45 +0100, Richard Heathfield wrote:

    On 13/05/2025 19:28, Mr Flibble wrote:
    On Mon, 12 May 2025 23:38:10 +0100, Andy Walker wrote:

    <snip>

    [For all I know, that's how PO already operates and he is
    not the
    sad misguided attention-seeking person that most here seem to
    assume,
    but is instead running a vast psychological experiment to see how >>>>>>> far he can push his LLM before anyone (other than our resident
    penguin) notices.]

    Several of my recent posts (e.g. Flibble's Leap) were AI generated >>>>>> and I don't mind admitting it: AI is a useful tool.

    /Flibble

    Do you wish to be able to mind admitting it: AI is a useful tool?

    eh? No.


    You are being a bit negative.

    Oh. ELIZA bears no resemblance to modern LLM AIs, dear.

    Good spot. But the principle is the same.

    Disagree.

    /Flibble

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andy Walker@21:1/5 to Mr Flibble on Tue May 13 23:59:02 2025
    On 13/05/2025 19:28, Mr Flibble wrote:
    On Mon, 12 May 2025 23:38:10 +0100, I wrote:
    [...] Sadly, it seems more likely
    that two or more posters will discover the joys of AI and set their
    computer to auto-reply semi-intelligently to each and every post.
    [For all I know, that's how PO already operates and he is not the
    sad misguided attention-seeking person that most here seem to assume,
    but is instead running a vast psychological experiment to see how far he
    can push his LLM before anyone (other than our resident penguin)
    notices.]
    Several of my recent posts (e.g. Flibble's Leap) were AI generated and I don't mind admitting it: AI is a useful tool.

    FTAOD, I have no objection to the use of AI to generate articles, whether wholly or in part. I /do/ take exception to the use of AI with
    intent to deceive, but that's another matter. In the present context,
    I wasn't worried about new articles that are AI-generated, but about the prospective use of AI to auto-reply. If two or more "authors" climb on
    that bandwagon, we could easily finish up with thousands of articles/day comprising "'tis" -- "'tisn't" -- "'tis so" -- "no 'tain't" ... exchanges instead of the current hundred or so.

    --
    Andy Walker, Nottingham.
    Andy's music pages: www.cuboid.me.uk/andy/Music
    Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Peerson

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