1. Forum
  2. Usenet
  3. COMP.THEORY

  • Re: HHH(DD) --- COMPUTE ACTUAL MAPPING FROM INPUT TO OUTPUT --- Trolls

    From joes@21:1/5 to All on Tue Apr 22 17:57:55 2025
    Am Tue, 22 Apr 2025 11:28:40 -0500 schrieb olcott:
    On 4/22/2025 7:57 AM, joes wrote:
    Am Tue, 15 Apr 2025 15:44:06 -0500 schrieb olcott:
    On 4/15/2025 2:03 PM, dbush wrote:
    On 4/15/2025 2:50 PM, olcott wrote:
    On 4/15/2025 11:05 AM, dbush wrote:
    On 4/15/2025 11:29 AM, olcott wrote:

    *corresponding output to the input*
    Not freaking allowed to look at any damn thing else besides the
    freaking input. Must compute whatever mapping ACTUALLY EXISTS FROM >>>>>>> THIS INPUT.
    So the algorithm HHH that you've implemented computes *some*
    computable function, but it does not compute the halting function
    as it is not computable.
    *corresponding output to the input*
    That doesn't refute anything I said.
    You continue to stupidly insist that int sum(int x, int y) {return x +
    y; }
    returns 7 for sum(3,2) because you incorrectly understand how these
    things fundamentally work.
    It is stupidly wrong to expect HHH(DD) report on the direct execution
    of DD when you are not telling it one damn thing about this direct
    execution.
    What else is it missing that the processor uses to execute it?
    The processor gets the exact same information, and HHH has access to an emulator.

    libx86emu <is> a correct x86 processor and does emulate its inputs
    correctly.
    No, it aborts instead of halting.

    The key thing here is that everyone has consistently flat out lied about
    the mapping from the above machine code to the behavior of DD emulated
    by HHH including HHH emulating itself emulating DD. They do this as a trollish head game.
    Don't project. If HHH does not map DD to its direct execution, it is
    not a halt decider.

    Everyone here stupidly assumes that the output must be derived from
    something THAT THE INPUT DOES NOT SAY.
    No, the program DD halts when directly executed, which is what we are interested in.

    HHH emulates DD including emulating itself emulating DD according the
    the semantics of the x86 language. Disagreeing with the semantics of the
    x86 language is as stupid as disagreeing with arithmetic.
    Despite multiple requests, you have never pointed to a disagreement with
    x86 semantics.

    --
    Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
    It is not guaranteed that n+1 exists for every n.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fred. Zwarts@21:1/5 to All on Tue Apr 22 20:07:10 2025
    Op 22.apr.2025 om 18:28 schreef olcott:
    On 4/22/2025 7:57 AM, joes wrote:
    Am Tue, 15 Apr 2025 15:44:06 -0500 schrieb olcott:
    On 4/15/2025 2:03 PM, dbush wrote:
    On 4/15/2025 2:50 PM, olcott wrote:
    On 4/15/2025 11:05 AM, dbush wrote:
    On 4/15/2025 11:29 AM, olcott wrote:

    *corresponding output to the input*
    Not freaking allowed to look at any damn thing else besides the
    freaking input. Must compute whatever mapping ACTUALLY EXISTS FROM >>>>>>> THIS INPUT.

    So the algorithm HHH that you've implemented computes *some*
    computable function, but it does not compute the halting function as >>>>>> it is not computable.

    *corresponding output to the input*

    That doesn't refute anything I said.

    You continue to stupidly insist that int sum(int x, int y) {return x +
    y; }
    returns 7 for sum(3,2) because you incorrectly understand how these
    things fundamentally work.

    It is stupidly wrong to expect HHH(DD) report on the direct execution of >>> DD when you are not telling it one damn thing about this direct
    execution.
    What else is it missing that the processor uses to execute it?


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

    _DD()
    [00002133] 55         push ebp      ; housekeeping
    [00002134] 8bec       mov ebp,esp   ; housekeeping
    [00002136] 51         push ecx      ; make space for local [00002137] 6833210000 push 00002133 ; push DD
    [0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
    [00002141] 83c404     add esp,+04
    [00002144] 8945fc     mov [ebp-04],eax
    [00002147] 837dfc00   cmp dword [ebp-04],+00
    [0000214b] 7402       jz 0000214f
    [0000214d] ebfe       jmp 0000214d
    [0000214f] 8b45fc     mov eax,[ebp-04]
    [00002152] 8be5       mov esp,ebp
    [00002154] 5d         pop ebp
    [00002155] c3         ret
    Size in bytes:(0035) [00002155]

    libx86emu <is> a correct x86 processor and does emulate
    its inputs correctly.

    The key thing here is that Olcott consistently does not understand that
    HHH is given a finite string input that according to the semantics of
    the x86 language specifies a halting program, as proven by direct
    execution and world-class simulators.
    He thinks that is correct that HHH assumes a different, a hypothetical
    input, namely another DD that is based on another hypothetical HHH that
    does not abort, instead of the actual input that specifies a DD based on
    the actual HHH that does abort.

    He assumes that is correct to think that the finite string specifies
    another behaviour, only because his simulator fails to reach the end of
    the simulation. This thinking violates the fact that according to the
    semantics of the x86 language, only one behaviour can be specified by
    the finite string.
    Disagreeing with the semantics of the x86 language is as stupid as
    disagreeing with arithmetic.

    He seems to believe that Sum(3,2) should return 9, because it is allowed
    to use the hypothetical inputs 4 and 5, instead of the actual inputs 3
    and 2, only because the programmer of the Sum function is unable to
    write correct code.

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