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

  • Re: What value should HHH(DD) correctly return? --- ChatGPT 5.0 analysi

    From Richard Heathfield@21:1/5 to olcott on Fri Aug 8 06:51:08 2025
    On 08/08/2025 01:05, olcott wrote:
    On 8/7/2025 6:27 PM, Richard Heathfield wrote:

    Let's see how [ChatGPT] copes with olcott's code:

    I am testing the assumption that simulating termination
    analyzer HHH correctly simulates its input until it:
    (a) Detects a non-terminating behavior pattern: abort
    simulation and return 0.
    (b) Simulated input reaches its simulated "return" statement:
    return 1.

    typedef int (*ptr)();
    int HHH(ptr P);

    int DD()
    {
       int Halt_Status = HHH(DD);
    ^^^^^^^^^^^^^^^^^^^^^^^^^
    <snip>

    Yet the real DD() is not an input to HHH

    Yeah it is. See quoted code.

    <snip>

    *Then it completely validates my whole proof*

    You clearly skipped over the part where it said you were talking
    complete bollocks:

    So if HHH predicts “halts”, the actual execution of DD will loop
    forever. That means HHH’s prediction was wrong — it said “halts”,
    but it doesn’t. So if HHH predicts “loops forever”, DD() actually terminates (returns 0 immediately). Again, prediction is wrong —
    it said “nonterminates”, but it halts. In both cases, whatever
    HHH returns is falsified by the actual behaviour of DD():

    --
    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 Kaz Kylheku@21:1/5 to olcott on Fri Aug 8 06:23:24 2025
    On 2025-08-08, olcott <[email protected]> wrote:
    Would DD correctly simulated by HHH reach its own simulated
    "return" statement final halt state?

    Listen, in your x86 simulator you had fatal flaws. Your code relied on
    the assumption that when the halting test case calls the simulator in
    order to obtaint he halting decision, it is calling the original one at
    the same address as the one that is doing the outermost deciding.

    This is not a requirement in the halting proof. The test case has a
    /copy/ of the halting decider.

    In your system, the test case can defeat your strategy easily like this: instead of just calling the halting decider (where your simulator then
    detects that the decider is running by looking at the instruction
    pointer), the test case can make a copy of the function and relocate it
    to another address, where it won't be recognized.

    You wrongly believe that a halting decider can detect the situation that
    the test case is using that same halting decider (and then behaving
    opposite).

    But this involves an undecidable problem. What problem is that? Namely, determining whether the test case in fact contains exactly the same
    decider as the one being applid to it.

    This requires calculating the equivalence of two programs.

    Calculating the equivalence of two programs is an undecidable problem in computer science, like universal halting. (It is easily shown
    undecidable by a reduction to an instance of the halting problem.)

    No, you cannot just assume that everything is in one x86 address space,
    and that the test case plays right into your hands by executing a JSR to
    the address of the halting decider you have provided. Why would
    it do that?

    Assume that the attacker has a copy of your halting decider and /embeds/
    it into the rebellious test case. The attacker doesn't have to embed a
    literal image of that halting decider as you have provided it. It can be translated to another language; for instance, the attacker can translate
    your decider into a proprietary byte code, and just include it as an
    array of byte code instructions executed by a VM they have written. The attacker can keep your x86 code, but randomly permute it so that it
    doesn't compare the same as a bit string.

    There is simply no way to reliably make the decision "aha! the test case
    has invoked a halting decider precisely equivalent to this one, and
    behaved in a contradictory manner!"

    The "halting decider precisely equivalent to this one" can look like
    anything! It can be written in any language, any style, disguised
    by endless permutations.

    --
    TXR Programming Language: http://nongnu.org/txr
    Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
    Mastodon: @[email protected]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Heathfield@21:1/5 to olcott on Fri Aug 8 17:21:30 2025
    On 08/08/2025 14:29, olcott wrote:
    On 8/8/2025 12:51 AM, Richard Heathfield wrote:
    On 08/08/2025 01:05, olcott wrote:
    On 8/7/2025 6:27 PM, Richard Heathfield wrote:

    Let's see how [ChatGPT] copes with olcott's code:

    I am testing the assumption that simulating termination
    analyzer HHH correctly simulates its input until it:
    (a) Detects a non-terminating behavior pattern: abort
    simulation and return 0.
    (b) Simulated input reaches its simulated "return" statement:
    return 1.

    typedef int (*ptr)();
    int HHH(ptr P);

    int DD()
    {
       int Halt_Status = HHH(DD);
           ^^^^^^^^^^^^^^^^^^^^^^^^^
    <snip>

    Yet the real DD() is not an input to HHH

    Yeah it is. See quoted code.

    <snip>

    *Then it completely validates my whole proof*

    You clearly skipped over the part where it said you were
    talking complete bollocks:

    So if HHH predicts “halts”, the actual execution of DD will
    loop forever. That means HHH’s prediction was wrong — it said
    “halts”, but it doesn’t. So if HHH predicts “loops forever”,
    DD() actually terminates (returns 0 immediately). Again,
    prediction is wrong — it said “nonterminates”, but it halts. In
    both cases, whatever HHH returns is falsified by the actual
    behaviour of DD():


    *You have to examine its final analysis*

    In the transcript I posted, I posted the whole thing. The whole
    thing said bollocks.

    https://chatgpt.com/share/68953d9e-6efc-8011-b266-502025818430
    Its final analysis agrees with my whole proof.

    So we now know that it will cheerfully take either side of the
    debate, depending on how you prime it. You therefore cannot
    reasonably point to it as supporting your side and *only* your side.

    <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 olcott on Fri Aug 8 19:26:59 2025
    On 08/08/2025 17:35, olcott wrote:
    When I tell it to make sure to test DD correctly
    simulated by HHH then ChatGPT 5.0 gets my same answer:

    And when I tell it (neutrally) to check that assumption, it says
    the assumption is bollocks... which it is.

    --
    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 olcott on Fri Aug 8 21:52:29 2025
    On 08/08/2025 20:24, olcott wrote:
    On 8/8/2025 1:26 PM, Richard Heathfield wrote:
    On 08/08/2025 17:35, olcott wrote:
    When I tell it to make sure to test DD correctly
    simulated by HHH then ChatGPT 5.0 gets my same answer:

    And when I tell it (neutrally) to check that assumption, it
    says the assumption is bollocks... which it is.


    Until you tell it to examine the behavior of DD
    correctly simulated by HHH as the only basis for
    a correct return value.

    As we have already established, HHH cannot correctly simulate DD
    sufficiently well to establish its return value. The assumption
    that it can is flawed, and your failure to realise this is what
    has cost you 22 years of bickering.

    --
    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 olcott on Fri Aug 8 23:31:20 2025
    On 08/08/2025 23:17, olcott wrote:
    DD emulated by HHH according to the semantics
    of the x86 language cannot possibly reach its
    own "ret" instruction final halt state.


    Let's accept that for a moment, and see where it leads us.

    You seem to be saying that HHH establishes that DD can't return.

    HHH must therefore return 0 (false means it doesn't halt).

    HHH assigns this to Halt_Status:


    so... Halt_Status = 0;

    if(Halt_Status)

    fails, so we fall past the if and land on:

    return Halt_Status;

    So DD returns after all, so HHH got it wrong.

    Accepting that HHH is correct proves that HHH is incorrect.
    Therefore the acceptance was erroneous.

    This is not rocket science. To understand this requires no
    mystical insight into magical x86 recursive bollocks. You just
    have to be able to follow along with your finger. So why can't you?

    --
    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 olcott on Sat Aug 9 00:09:54 2025
    On 08/08/2025 23:33, olcott wrote:
    On 8/8/2025 5:31 PM, Richard Heathfield wrote:

    <snip>


    if(Halt_Status)


    *is unreachable from DD correctly simulated by HHH*

    Are you saying HHH never returns to its caller? If so, you have
    nothing.

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