1. Forum
  2. Usenet
  3. COMP.THEORY

  • Re: Computable Functions --- OUTPUTS MUST CORRESPOND TO INPUTS

    From Fred. Zwarts@21:1/5 to All on Tue Apr 22 21:33:18 2025
    Op 22.apr.2025 om 20:51 schreef olcott:
    On 4/22/2025 1:07 PM, Fred. Zwarts wrote:
    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,

    That is stupidly incorrect. The only question that HHH
    must answer is the behavior that its input specifies.

    Yes and the input, a finite string specifies a halting program according
    to the unique semantics of the x86 language, as proven by direct
    execution and world-class simulators. HHH's failure to reach the end of
    the simulation does not show otherwise.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fred. Zwarts@21:1/5 to All on Wed Apr 23 11:05:22 2025
    Op 22.apr.2025 om 21:51 schreef olcott:
    On 4/22/2025 2:33 PM, Fred. Zwarts wrote:
    Op 22.apr.2025 om 20:51 schreef olcott:
    On 4/22/2025 1:07 PM, Fred. Zwarts wrote:
    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,

    That is stupidly incorrect. The only question that HHH
    must answer is the behavior that its input specifies.

    Yes and the input, a finite string specifies a halting program
    according to the unique semantics of the x86 language, as proven by
    direct execution and world-class simulators. HHH's failure to reach
    the end of the simulation does not show otherwise.

    I have proven that the directly executed DD and DD
    emulated by HHH according to the semantics of the
    x86 language have a different set of state changes
    many hundreds of times for several years.

    We have never seen a proof, only your unbased claims. You never showed
    the first state change that is different for direct execution and the simulation. You only showed a HHH that fails to reach the end of a
    halting program.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From joes@21:1/5 to All on Wed Apr 23 11:25:34 2025
    Am Tue, 22 Apr 2025 13:51:48 -0500 schrieb olcott:
    On 4/22/2025 1:07 PM, Fred. Zwarts wrote:
    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:

    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?

    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,

    That is stupidly incorrect.
    No, DD halts (when executed directly). HHH is not a halt decider, not even
    for DD only.

    People here stupidly assume that the outputs are not required to
    correspond to the inputs.
    But the direct execution of DD is computable from its description.

    --
    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 Wed Apr 23 19:39:08 2025
    Op 23.apr.2025 om 17:40 schreef olcott:
    On 4/23/2025 4:05 AM, Fred. Zwarts wrote:
    Op 22.apr.2025 om 21:51 schreef olcott:
    On 4/22/2025 2:33 PM, Fred. Zwarts wrote:
    Op 22.apr.2025 om 20:51 schreef olcott:
    On 4/22/2025 1:07 PM, Fred. Zwarts wrote:
    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,

    That is stupidly incorrect. The only question that HHH
    must answer is the behavior that its input specifies.

    Yes and the input, a finite string specifies a halting program
    according to the unique semantics of the x86 language, as proven by
    direct execution and world-class simulators. HHH's failure to reach
    the end of the simulation does not show otherwise.

    I have proven that the directly executed DD and DD
    emulated by HHH according to the semantics of the
    x86 language have a different set of state changes
    many hundreds of times for several years.

    We have never seen a proof, only your unbased claims. You never showed
    the first state change that is different for direct execution and the
    simulation. You only showed a HHH that fails to reach the end of a
    halting program.

    _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]

    Even the above is complete proof to everyone that
    knows the x86 language.


    No trace of a proof. Which of the state changes in the above program is different between the simulation and the direct execution? The only
    difference is that the simulation aborts prematurely and the direct
    execution does not abort.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fred. Zwarts@21:1/5 to All on Wed Apr 23 19:44:05 2025
    Op 23.apr.2025 om 17:32 schreef olcott:
    On 4/23/2025 6:25 AM, joes wrote:
    Am Tue, 22 Apr 2025 13:51:48 -0500 schrieb olcott:
    On 4/22/2025 1:07 PM, Fred. Zwarts wrote:
    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:

    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?

    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,

    That is stupidly incorrect.
    No, DD halts (when executed directly). HHH is not a halt decider, not
    even
    for DD only.

    People here stupidly assume that the outputs are not required to
    correspond to the inputs.
    But the direct execution of DD is computable from its description.


    Not as an input to HHH.
    When HHH computes halting for DD is is only allowed
    to apply the finite string transformations specified
    by the x86 language to the machine code of DD.

    Because DD DOES CALL ITS OWN EMULATOR this does require
    the behavior measured is DD emulating by HHH including
    HHH emulating itself emulating DDD.

    Indeed, HHH fails to see the finite recursion completely, because HHH
    aborts and therefore does not reach the end of the halting program.
    This makes HHH blind for the behaviour of the program specified by the
    finite string.
    Indeed, a blind program cannot see the correct behaviour of the input.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Wed Apr 23 18:40:02 2025
    On 4/23/25 11:40 AM, olcott wrote:
    On 4/23/2025 4:05 AM, Fred. Zwarts wrote:
    Op 22.apr.2025 om 21:51 schreef olcott:
    On 4/22/2025 2:33 PM, Fred. Zwarts wrote:
    Op 22.apr.2025 om 20:51 schreef olcott:
    On 4/22/2025 1:07 PM, Fred. Zwarts wrote:
    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,

    That is stupidly incorrect. The only question that HHH
    must answer is the behavior that its input specifies.

    Yes and the input, a finite string specifies a halting program
    according to the unique semantics of the x86 language, as proven by
    direct execution and world-class simulators. HHH's failure to reach
    the end of the simulation does not show otherwise.

    I have proven that the directly executed DD and DD
    emulated by HHH according to the semantics of the
    x86 language have a different set of state changes
    many hundreds of times for several years.

    We have never seen a proof, only your unbased claims. You never showed
    the first state change that is different for direct execution and the
    simulation. You only showed a HHH that fails to reach the end of a
    halting program.

    _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]

    Even the above is complete proof to everyone that
    knows the x86 language.


    Sure, it proves you don't know what you are talking about as the code is incomplete as it doesn't include the code at 000015c3, so has no
    actually defined behavior.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Wed Apr 23 22:41:58 2025
    On 4/23/25 11:32 AM, olcott wrote:
    On 4/23/2025 6:25 AM, joes wrote:
    Am Tue, 22 Apr 2025 13:51:48 -0500 schrieb olcott:
    On 4/22/2025 1:07 PM, Fred. Zwarts wrote:
    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:

    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?

    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,

    That is stupidly incorrect.
    No, DD halts (when executed directly). HHH is not a halt decider, not
    even
    for DD only.

    People here stupidly assume that the outputs are not required to
    correspond to the inputs.
    But the direct execution of DD is computable from its description.


    Not as an input to HHH.

    But neither the "direct execution" or the "simulation by HHH" are
    "inputs" to HHH. What is the input is the representation of the program
    to be decided on.

    When HHH computes halting for DD is is only allowed
    to apply the finite string transformations specified
    by the x86 language to the machine code of DD.

    It is only ABLE to apply them.

    The REQUIREMENT to be correct are not limited to computable transformation.

    The Halting Function will map the finite string representation of DD to Halting, since you have indicated that HHH will transform the
    representation of DD to a string indicating non-halting, and DD will
    then map that non-halting indication to a halting behavior.

    That HHH transformed the input to the wrong string for what the Halting
    Mapping defined, just says it isn't a correct Halting Decider, but maybe
    is a correct POOP decider it that is houw you are defining your other
    problems mapping.


    Because DD DOES CALL ITS OWN EMULATOR this does require
    the behavior measured is DD emulating by HHH including
    HHH emulating itself emulating DDD.

    No. because that isn't what HHH does. HHH needs to see DD calling
    HHH(DD) as asking HHH what it will answer about that input.

    One problem is that you keep on saying you are going by the x86
    instruction set, and that says NOTHING like what you are claiming. HHH
    sees a call HHH instruction inside DD, and thus the only correct
    simulation would be to go into HHH (assuming it is part of the input, if
    not then it just can't do a correct x86 simulation). And after each instruction, the only correct simulation is to simulate the next
    instruction.

    If HHH is defined to be a correct simulator, then it is not allowed to
    stop and return, as that isn't the behavior of a correct simulator
    (which means it can't have that definition and also be a decider)

    If HHH is defined to be a decider, and thus must stop, then is have
    admitted that it isn't a correct simulation, and thus it doesn't
    determine the behavior of its input, which is DEFINED based on the
    direct exectution or COMPLETE and correct simulation of that input.

    If its criteria is to answer based on it own correct simulation, then
    the criteria is just proven to be incorrect and self-contradictory. That
    is why in the ACTUAL problem, the behavior the answer is based on is NOT
    what the decider gets from its simulation, but what the actual direct
    exectuion would be, which is an objective standard.


    Anyone that disagrees merely proves their own lack
    of understanding that computable functions are only
    allowed to apply finite string transformations to inputs.


    So? HHH *WILL* do some finite string transformation, and when it sees DD
    use its copy of HHH, that same finite string transformation is all can correctly see happen.

    Since HHH(DD) return non-halting, that is the only CORRECT interpreation
    of that call, if HHH can't figure that out, then it is just working off incorrect assumptions.

    The problem you have is that you are just FALSELY ASSUMING that the
    function that HHH is being asked to compute is computable. In fact, the meta-question of the problem is the question of IF it IS computable, and
    it turns out that the answer is no, and no such decider can exist that
    is correct for all inputs.

    The fact that HHH needs to be actually correct seems to be beyond your understanding, in part because you don't understand what truth actually is.

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