• Re: Proof that DDD specifies non-halting behavior --- point by point

    From Richard Damon@21:1/5 to olcott on Tue Aug 13 22:29:51 2024
    On 8/13/24 8:52 PM, olcott wrote:
    void DDD()
    {
      HHH(DDD);
      return;
    }

    _DDD()
    [00002172] 55         push ebp      ; housekeeping
    [00002173] 8bec       mov ebp,esp   ; housekeeping
    [00002175] 6872210000 push 00002172 ; push DDD
    [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
    [0000217f] 83c404     add esp,+04
    [00002182] 5d         pop ebp
    [00002183] c3         ret
    Size in bytes:(0018) [00002183]

    A simulation of N instructions of DDD by HHH according to
    the semantics of the x86 language is necessarily correct.


    Nope, it is just the correct PARTIAL emulation of the first N
    instructions of DDD, and not of all of DDD, in particular, it says
    NOTHING about the behavior of the rest of the instructions of DDD.

    A correct simulation of N instructions of DDD by HHH is
    sufficient to correctly predict the behavior of an unlimited
    simulation.

    Nope, if a HHH returns to its caller, the correct emulation of the DDD
    that calls that HHH when correctly emulated by an unlimited emulator
    WILL reach its final instruction, as it will see DDD call HHH, then HHH
    emulate N instructions of a copy of DDD, then abort its emulation and
    return to its caller, which is DDD, which will return.


    Termination analyzers / halt deciders are only required
    to correctly predict the behavior of their inputs.

    Termination analyzers / halt deciders are only required
    to correctly predict the behavior of their inputs, thus
    the behavior of non-inputs is outside of their domain.


    And that behavior that they are REQUIRED to report on is the behavior of
    the direct exectuion of the machine the input FULLY represents.

    THAT IS DEFINITION.

    If the "halt decider" tries to consider anything else that doesn't give
    the exact same answer as the behavior of the input, it just isn't a halt decider.

    THAT IS DEFINITION.

    Sorry, you are just showing your self-made ignorance.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Tue Aug 13 23:21:33 2024
    On 8/13/24 10:38 PM, olcott wrote:
    On 8/13/2024 9:29 PM, Richard Damon wrote:
    On 8/13/24 8:52 PM, olcott wrote:
    void DDD()
    {
       HHH(DDD);
       return;
    }

    _DDD()
    [00002172] 55         push ebp      ; housekeeping
    [00002173] 8bec       mov ebp,esp   ; housekeeping
    [00002175] 6872210000 push 00002172 ; push DDD
    [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
    [0000217f] 83c404     add esp,+04
    [00002182] 5d         pop ebp
    [00002183] c3         ret
    Size in bytes:(0018) [00002183]

    A simulation of N instructions of DDD by HHH according to
    the semantics of the x86 language is necessarily correct.


    Nope, it is just the correct PARTIAL emulation of the first N
    instructions of DDD, and not of all of DDD,

    That is what I said dufuss.

    Nope. You didn't. I added clairifying words, pointing out why you claim
    is incorrect.

    For an emulation to be "correct" it must be complete, as partial
    emulations are only partially correct, so without the partial modifier,
    they are not correct.



    A correct simulation of N instructions of DDD by HHH is
    sufficient to correctly predict the behavior of an unlimited
    simulation.

    Nope, if a HHH returns to its caller,

    *Try to show exactly how DDD emulated by HHH returns to its caller*
    (the first one doesn't even have a caller)
    Use the above machine language instructions to show this.


    Remember how English works:

    When you ask "How DDD emulated by HHH returns to its callers".

    The SUBJECT of the sentence is "DDD", that is the name of a PROGRAM, and
    DDD includes all the code of HHH, If it doesn't we can't even correctly
    emulate DDD past the call instruction.

    The VERB of the sentence is "Returns" that is the action of DDD that we
    are talking about.

    The OBJECT of the sentence is "its callers" which indicates who we are
    asking if DDD returns to.

    The phrase "emulated by HHH" is a modifier phrase attached to DDD to
    specify which of potential different DDDs we are talking about, and make
    it clear that we are talking about the DDD that calls the HHH that we
    are talking abut.

    Thus, the behavior of that DDD, is to call HHH(DDD), at which point this subroutine HHH will emulate the code specified by its input to emulate N instructions, in that time it will not reach a final state, and so it
    will return the value 0 to its caller, which is DDD, and DDD will then
    return to its caller, showing how it does it.


    The sentence you seem to want to talk about would be something more like:

    The simulation of DDD by HHH will never return to its caller.

    Here, the subject is the "simulation", of what: DDD, by whom: HHH.

    Yes, that simulation will never reach a return of DDD, so that statement
    would be true.

    The problem is that it makes it clear that if HHH aborts is simulation
    that is only partial that clearly doesn't mean that the full simulation
    of the input would be non-halting.

    And that clarity is your problem, because it breaks your next step.

    Your argument NEEDS there to be wiggle room to switch meaning, because
    it needs to generate the needed LIE by doing that.

    Sorry, you are just proving that you just don't know what you are
    talking about, or that you are just pathetically a pathological liar
    that doesn't care how much you lie.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Wed Aug 14 00:04:23 2024
    On 8/13/24 11:48 PM, olcott wrote:
    On 8/13/2024 10:21 PM, Richard Damon wrote:
    On 8/13/24 10:38 PM, olcott wrote:
    On 8/13/2024 9:29 PM, Richard Damon wrote:
    On 8/13/24 8:52 PM, olcott wrote:
    void DDD()
    {
       HHH(DDD);
       return;
    }

    _DDD()
    [00002172] 55         push ebp      ; housekeeping
    [00002173] 8bec       mov ebp,esp   ; housekeeping
    [00002175] 6872210000 push 00002172 ; push DDD
    [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
    [0000217f] 83c404     add esp,+04
    [00002182] 5d         pop ebp
    [00002183] c3         ret
    Size in bytes:(0018) [00002183]

    A simulation of N instructions of DDD by HHH according to
    the semantics of the x86 language is necessarily correct.


    Nope, it is just the correct PARTIAL emulation of the first N
    instructions of DDD, and not of all of DDD,

    That is what I said dufuss.

    Nope. You didn't. I added clairifying words, pointing out why you
    claim is incorrect.

    For an emulation to be "correct" it must be complete, as partial
    emulations are only partially correct, so without the partial
    modifier, they are not correct.


    A complete emulation of one instruction is
    a complete emulation of one instruction






    A correct simulation of N instructions of DDD by HHH is
    sufficient to correctly predict the behavior of an unlimited
    simulation.

    Nope, if a HHH returns to its caller,

    *Try to show exactly how DDD emulated by HHH returns to its caller*
    (the first one doesn't even have a caller)
    Use the above machine language instructions to show this.


    Remember how English works:

    When you ask "How DDD emulated by HHH returns to its callers".

    Show the exact machine code trace of how DDD emulated
    by HHH (according to the semantics of the x86 language)
    reaches its own machine address 00002183

    No. The trace is to long, and since you HHH doesn't meet your
    requirements (since it isn't a pure function) you can't give me a
    compldte input to trace.

    If the input DDD is just what you show below, your problem has a
    category error as that isn't a complete program, and thus not something
    that can be completely traced.


    _DDD()
    [00002172] 55         push ebp      ; housekeeping
    [00002173] 8bec       mov ebp,esp   ; housekeeping
    [00002175] 6872210000 push 00002172 ; push DDD
    [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
    [0000217f] 83c404     add esp,+04
    [00002182] 5d         pop ebp
    [00002183] c3         ret
    Size in bytes:(0018) [00002183]

    When DDD is emulated by HHH
    HHH emulates the lines of DDD in this order:
    [00002172]
    [00002173]
    [00002175]
    [0000217a] calls HHH(DDD)

    And here you show that you don't understand what a correct by x86
    semantics means.

    Following the call to HHH, must be the instuctions of HHH being emulated.

    THAT *IS* the requirements of emulation by the semantics of the x86
    language.

    Since HHH(DDD) is know to return, if HHH actually WAS a pure function,
    then this call MUST return to DDD.

    You are just shown how stuoid you are.


    which emulates the lines of DDD in this order
    HHH emulates the lines of DDD in this order:
    [00002172]
    [00002173]
    [00002175]
    [0000217a]

    with 200 pages of HHH emulating itself emulating
    DDD inbetween.



    No, about 300 lines. (if we allow the skipping of the actual OS code
    that your trace skips). The 200 pages is the trace of the HHH deciding
    on the input, not the trace it DOES of the input. That has about 1-2 instructions emulated per page of trace.

    Obviously you don't read the message, I guess you are just to stupid to understand long posts.

    You are just PROVING you are just a self-made idiot that just doesn't
    know what he is talking about, and so stupid that he doesn't realize he
    is an idiot, which is the worse kind.

    That, you are you no sense of ethics that make you want to even try to
    tell the truth, because you think lying is just fine.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From joes@21:1/5 to All on Wed Aug 14 07:43:50 2024
    Am Tue, 13 Aug 2024 21:38:07 -0500 schrieb olcott:
    On 8/13/2024 9:29 PM, Richard Damon wrote:
    On 8/13/24 8:52 PM, olcott wrote:

    A simulation of N instructions of DDD by HHH according to the
    semantics of the x86 language is necessarily correct.
    Nope, it is just the correct PARTIAL emulation of the first N
    instructions of DDD, and not of all of DDD,
    That is what I said dufuss.
    You were trying to label an incomplete/partial/aborted simulation
    as correct.

    A correct simulation of N instructions of DDD by HHH is sufficient to
    correctly predict the behavior of an unlimited simulation.
    Nope, if a HHH returns to its caller,
    *Try to show exactly how DDD emulated by HHH returns to its caller*
    how *HHH* returns

    (the first one doesn't even have a caller)
    Use the above machine language instructions to show this.
    HHH simulates DDD enter the matrix
    DDD calls HHH(DDD) Fred: could be eliminated
    HHH simulates DDD second level
    DDD calls HHH(DDD) recursion detected
    HHH aborts, returns outside interference
    DDD halts voila
    HHH halts

    --
    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 Aug 14 11:09:40 2024
    Op 14.aug.2024 om 02:52 schreef olcott:
    void DDD()
    {
      HHH(DDD);
      return;
    }

    _DDD()
    [00002172] 55         push ebp      ; housekeeping
    [00002173] 8bec       mov ebp,esp   ; housekeeping
    [00002175] 6872210000 push 00002172 ; push DDD
    [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
    [0000217f] 83c404     add esp,+04
    [00002182] 5d         pop ebp
    [00002183] c3         ret
    Size in bytes:(0018) [00002183]


    Again the same joke? It seems you are short of memory.

    A simulation of N instructions of DDD by HHH according to
    the semantics of the x86 language is necessarily correct.

    It is only a correct start of an incomplete simulation.


    A correct simulation of N instructions of DDD by HHH is
    sufficient to correctly predict the behavior of an unlimited
    simulation.

    It is not, since the semantics of the x86 language, used in the direct execution of the same input, shows that DDD halts.
    It is clear that HHH aborts its own simulation one cycle to soon. The
    simulated HHH had only one cycle to go, when aborted. Therefore, the
    prediction of a non-halting behaviour is premature.


    Termination analyzers / halt deciders are only required
    to correctly predict the behavior of their inputs.

    Exactly. And this is the same input that, when used in direct execution,
    halts.


    Termination analyzers / halt deciders are only required
    to correctly predict the behavior of their inputs, thus
    the behavior of non-inputs is outside of their domain.


    Indeed, so your dreams of a HHH that does not abort and does not halt,
    is a non-input and is outside the domain.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mikko@21:1/5 to olcott on Wed Aug 14 11:17:10 2024
    On 2024-08-14 00:52:36 +0000, olcott said:

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

    In order to prove that the above specifies a non-halting behavour
    you must prove that HHH(DDD) does not terminate.

    --
    Mikko

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Wed Aug 14 07:22:53 2024
    On 8/14/24 12:24 AM, olcott wrote:
    On 8/13/2024 11:04 PM, Richard Damon wrote:
    On 8/13/24 11:48 PM, olcott wrote:
    On 8/13/2024 10:21 PM, Richard Damon wrote:
    On 8/13/24 10:38 PM, olcott wrote:
    On 8/13/2024 9:29 PM, Richard Damon wrote:
    On 8/13/24 8:52 PM, olcott wrote:
    void DDD()
    {
       HHH(DDD);
       return;
    }

    _DDD()
    [00002172] 55         push ebp      ; housekeeping
    [00002173] 8bec       mov ebp,esp   ; housekeeping
    [00002175] 6872210000 push 00002172 ; push DDD
    [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
    [0000217f] 83c404     add esp,+04
    [00002182] 5d         pop ebp
    [00002183] c3         ret
    Size in bytes:(0018) [00002183]

    A simulation of N instructions of DDD by HHH according to
    the semantics of the x86 language is necessarily correct.


    Nope, it is just the correct PARTIAL emulation of the first N
    instructions of DDD, and not of all of DDD,

    That is what I said dufuss.

    Nope. You didn't. I added clairifying words, pointing out why you
    claim is incorrect.

    For an emulation to be "correct" it must be complete, as partial
    emulations are only partially correct, so without the partial
    modifier, they are not correct.


    A complete emulation of one instruction is
    a complete emulation of one instruction






    A correct simulation of N instructions of DDD by HHH is
    sufficient to correctly predict the behavior of an unlimited
    simulation.

    Nope, if a HHH returns to its caller,

    *Try to show exactly how DDD emulated by HHH returns to its caller*
    (the first one doesn't even have a caller)
    Use the above machine language instructions to show this.


    Remember how English works:

    When you ask "How DDD emulated by HHH returns to its callers".

    Show the exact machine code trace of how DDD emulated
    by HHH (according to the semantics of the x86 language)
    reaches its own machine address 00002183

    No. The trace is to long,

    Show the Trace of DDD emulated by HHH
    and show the trace of DDD emulated by HHH
    emulated by the executed HHH
    Just show the DDD code traces.


    First you need to make a DDD that meets the requirements, and that means
    that it calls an HHH that meets the requirements.

    Since you HHH doesn't, I can't show what isn't there yet.

    The biggest problem with HHH is that it isn't pure function of just its declared inputs, it detects via a side channel if it is the "root"
    emulator, and changes its behavior because of that.

    So, since we don't have an actual DDD that meets its requirements, we
    can't make a correct trace of it to show what it does.

    Second, you have an incoherent requiremnet in your challenge, the "trace
    of DDD emulated by HHH" will not be created by HHH, since your HHH
    doesn't do a complete emulation, and your requirement is for a complete
    trace, so you are just creating a strawman deception.

    It shouldn't be too hard for a decent programmer to actually make the
    required HHH, but from what I see of your code, you are not one of
    those. Of course, getting it to behave like you want would be tougher,
    as you need to program in a BUG make it ignore the conditionals inside
    of HHH when it emulates the input.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From joes@21:1/5 to All on Wed Aug 14 13:25:48 2024
    Am Wed, 14 Aug 2024 08:14:42 -0500 schrieb olcott:
    On 8/14/2024 2:43 AM, joes wrote:
    Am Tue, 13 Aug 2024 21:38:07 -0500 schrieb olcott:
    On 8/13/2024 9:29 PM, Richard Damon wrote:
    On 8/13/24 8:52 PM, olcott wrote:

    A simulation of N instructions of DDD by HHH according to the
    semantics of the x86 language is necessarily correct.
    Nope, it is just the correct PARTIAL emulation of the first N
    instructions of DDD, and not of all of DDD,
    That is what I said dufuss.
    You were trying to label an incomplete/partial/aborted simulation as
    correct.
    When one instruction of DDD is correctly emulated then one instruction
    was correctly emulated.
    Only one, so not all.

    A correct simulation of N instructions of DDD by HHH is sufficient
    to correctly predict the behavior of an unlimited simulation.
    Nope, if a HHH returns to its caller,
    *Try to show exactly how DDD emulated by HHH returns to its caller*
    how *HHH* returns
    Changing the question is the strawman error or reasoning.
    Richard was talking about HHH returning.

    (the first one doesn't even have a caller)
    Use the above machine language instructions to show this.
    HHH simulates DDD enter the matrix
    DDD calls HHH(DDD) Fred: could be eliminated
    HHH simulates DDD second level
    DDD calls HHH(DDD) recursion detected
    HHH aborts, returns outside interference
    DDD halts voila
    HHH halts

    That is the strawman error of reasoning.
    This is not a misrepresentation of your position, this is mine.

    DDD correctly emulated by HHH never reaches its own "return"
    instruction. Show how it does or admit that I am correct.
    See above. Show the error.

    --
    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 joes@21:1/5 to and that was a direct reply. As Fre on Wed Aug 14 13:56:44 2024
    Am Wed, 14 Aug 2024 08:38:51 -0500 schrieb olcott:
    On 8/14/2024 3:17 AM, Mikko wrote:
    On 2024-08-14 00:52:36 +0000, olcott said:

    void DDD()
    {
       HHH(DDD);
       return;
    }
    In order to prove that the above specifies a non-halting behavour you
    must prove that HHH(DDD) does not terminate.
    What is wrong about that?

    That is the strawman error of reasoning.
    Not at all. A strawman is a wrong presentation of opposing arguments.
    There aren't even any arguments here.

    The focus of the post was to show that DDD emulated by HHH according to
    the semantics of the x86 language cannot possibly reach its own "return" instruction.
    Yes, and that was a direct reply. As Fred said, DDD could be replaced
    by a direct call to HHH(HHH).

    By changing the subject you cheat.
    You are avoiding questions.

    --
    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 joes@21:1/5 to All on Wed Aug 14 13:26:39 2024
    Am Wed, 14 Aug 2024 08:06:27 -0500 schrieb olcott:
    On 8/14/2024 3:17 AM, Mikko wrote:
    On 2024-08-14 00:52:36 +0000, olcott said:

    void DDD()
    {
       HHH(DDD);
       return;
    }
    In order to prove that the above specifies a non-halting behavour you
    must prove that HHH(DDD) does not terminate.

    Wrong.
    How can DDD not halt if HHH does?

    --
    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 Aug 14 16:27:51 2024
    Op 14.aug.2024 om 15:38 schreef olcott:
    On 8/14/2024 3:17 AM, Mikko wrote:
    On 2024-08-14 00:52:36 +0000, olcott said:

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

    In order to prove that the above specifies a non-halting behavour
    you must prove that HHH(DDD) does not terminate.


    That is the strawman error of reasoning.

    The focus of the post was to show that DDD emulated by HHH
    according to the semantics of the x86 language cannot possibly
    reach its own "return" instruction.
    A simulation that fails to reach the end is never correct.
    It is the strawmen error to think that a correct start of a simulation
    makes the whole simulation correct.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fred. Zwarts@21:1/5 to All on Wed Aug 14 16:31:21 2024
    Op 14.aug.2024 om 15:18 schreef olcott:
    On 8/14/2024 4:09 AM, Fred. Zwarts wrote:
    Op 14.aug.2024 om 02:52 schreef olcott:
    void DDD()
    {
       HHH(DDD);
       return;
    }

    _DDD()
    [00002172] 55         push ebp      ; housekeeping
    [00002173] 8bec       mov ebp,esp   ; housekeeping
    [00002175] 6872210000 push 00002172 ; push DDD
    [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
    [0000217f] 83c404     add esp,+04
    [00002182] 5d         pop ebp
    [00002183] c3         ret
    Size in bytes:(0018) [00002183]


    Again the same joke? It seems you are short of memory.

    A simulation of N instructions of DDD by HHH according to
    the semantics of the x86 language is necessarily correct.

    It is only a correct start of an incomplete simulation.


    When one instruction is emulated completely then this
    is a complete emulation of one instruction.

    That is what I said: It is the correct start of the simulation of a
    program. But for the correct simulation of the program we need more.



    A correct simulation of N instructions of DDD by HHH is
    sufficient to correctly predict the behavior of an unlimited
    simulation.

    It is not,

    When one instruction is emulated completely then this
    is a complete emulation of one instruction.
    Until you agree with that we are dead in the water.

    I agreed already that the correct simulation of one instruction is the
    correct start of the simulation of a program. But for the correct
    simulation of the program we need more.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fred. Zwarts@21:1/5 to All on Wed Aug 14 16:25:34 2024
    Op 14.aug.2024 om 15:14 schreef olcott:
    On 8/14/2024 2:43 AM, joes wrote:
    Am Tue, 13 Aug 2024 21:38:07 -0500 schrieb olcott:
    On 8/13/2024 9:29 PM, Richard Damon wrote:
    On 8/13/24 8:52 PM, olcott wrote:

    A simulation of N instructions of DDD by HHH according to the
    semantics of the x86 language is necessarily correct.
    Nope, it is just the correct PARTIAL emulation of the first N
    instructions of DDD, and not of all of DDD,
    That is what I said dufuss.
    You were trying to label an incomplete/partial/aborted simulation
    as correct.



    When one instruction of DDD is correctly emulated then one
    instruction was correctly emulated.

    A correct simulation of N instructions of DDD by HHH is sufficient to >>>>> correctly predict the behavior of an unlimited simulation.
    Nope, if a HHH returns to its caller,
    *Try to show exactly how DDD emulated by HHH returns to its caller*
    how *HHH* returns


    Changing the question is the strawman error or reasoning.

    (the first one doesn't even have a caller)
    Use the above machine language instructions to show this.
    HHH simulates DDD    enter the matrix
       DDD calls HHH(DDD)    Fred: could be eliminated
       HHH simulates DDD    second level
         DDD calls HHH(DDD)    recursion detected
       HHH aborts, returns    outside interference
       DDD halts        voila
    HHH halts


    That is the strawman error of reasoning.
    DDD correctly emulated by HHH never reaches its own "return"
    instruction. Show how it does or admit that I am correct.


    Only because the HHH simulated by HHH was not allowed by the simulating
    HHH to continue up to the end. The simulating HHH aborted one cycle too
    soon. So, the only reason why the simulation does not reach the end is
    that the simulation is incomplete.
    Every simulation that aborts is incomplete.


    --
    Paradoxes in the relation between Creator and creature. <http://www.wirholt.nl/English>.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Terry@21:1/5 to joes on Wed Aug 14 16:07:43 2024
    On 14/08/2024 08:43, joes wrote:
    Am Tue, 13 Aug 2024 21:38:07 -0500 schrieb olcott:
    On 8/13/2024 9:29 PM, Richard Damon wrote:
    On 8/13/24 8:52 PM, olcott wrote:

    A simulation of N instructions of DDD by HHH according to the
    semantics of the x86 language is necessarily correct.
    Nope, it is just the correct PARTIAL emulation of the first N
    instructions of DDD, and not of all of DDD,
    That is what I said dufuss.
    You were trying to label an incomplete/partial/aborted simulation
    as correct.

    A correct simulation of N instructions of DDD by HHH is sufficient to
    correctly predict the behavior of an unlimited simulation.
    Nope, if a HHH returns to its caller,
    *Try to show exactly how DDD emulated by HHH returns to its caller*
    how *HHH* returns

    (the first one doesn't even have a caller)
    Use the above machine language instructions to show this.
    HHH simulates DDD enter the matrix
    DDD calls HHH(DDD) Fred: could be eliminated
    HHH simulates DDD second level
    DDD calls HHH(DDD) recursion detected
    HHH aborts, returns outside interference
    DDD halts voila
    HHH halts

    You're misunderstanding the scenario? If your simulated HHH aborts its simulation [line 5 above],
    then the outer level H would have aborted its identical simulation earlier. You know that, right?
    [It's what people have been discussing here endlessly for the last few months! :) ]

    So your trace is impossible...


    Mike.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From joes@21:1/5 to All on Wed Aug 14 19:26:40 2024
    Am Wed, 14 Aug 2024 08:18:18 -0500 schrieb olcott:
    On 8/14/2024 4:09 AM, Fred. Zwarts wrote:
    Op 14.aug.2024 om 02:52 schreef olcott:

    A simulation of N instructions of DDD by HHH according to the
    semantics of the x86 language is necessarily correct.
    It is only a correct start of an incomplete simulation.
    When one instruction is emulated completely then this is a complete
    emulation of one instruction.
    And not an emulation of all instructions.

    A correct simulation of N instructions of DDD by HHH is sufficient to
    correctly predict the behavior of an unlimited simulation.
    It is not,
    When one instruction is emulated completely then this is a complete
    emulation of one instruction.
    Until you agree with that we are dead in the water.
    That's on you.

    Termination analyzers / halt deciders are only required to correctly
    predict the behavior of their inputs.
    Exactly. And this is the same input that, when used in direct
    execution, halts.

    Termination analyzers / halt deciders are only required to correctly
    predict the behavior of their inputs, thus the behavior of non-inputs
    is outside of their domain.
    Indeed, so your dreams of a HHH that does not abort and does not halt,
    is a non-input and is outside the domain.

    --
    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 joes@21:1/5 to All on Thu Aug 15 07:00:43 2024
    Am Wed, 14 Aug 2024 16:07:43 +0100 schrieb Mike Terry:
    On 14/08/2024 08:43, joes wrote:
    Am Tue, 13 Aug 2024 21:38:07 -0500 schrieb olcott:
    On 8/13/2024 9:29 PM, Richard Damon wrote:
    On 8/13/24 8:52 PM, olcott wrote:

    A simulation of N instructions of DDD by HHH according to the
    semantics of the x86 language is necessarily correct.
    Nope, it is just the correct PARTIAL emulation of the first N
    instructions of DDD, and not of all of DDD,
    That is what I said dufuss.
    You were trying to label an incomplete/partial/aborted simulation as
    correct.

    A correct simulation of N instructions of DDD by HHH is sufficient
    to correctly predict the behavior of an unlimited simulation.
    Nope, if a HHH returns to its caller,
    *Try to show exactly how DDD emulated by HHH returns to its caller*
    how *HHH* returns

    HHH simulates DDD enter the matrix
    DDD calls HHH(DDD) Fred: could be eliminated HHH simulates
    DDD
    second level
    DDD calls HHH(DDD) recursion detected
    HHH aborts, returns outside interference DDD halts
    voila
    HHH halts

    You're misunderstanding the scenario? If your simulated HHH aborts its simulation [line 5 above],
    then the outer level H would have aborted its identical simulation
    earlier. You know that, right?
    Of course. I made it only to illustrate one step in the paradoxical
    reasoning, as long as we're calling programs that do or don't abort
    the same.

    So your trace is impossible...
    Just like all the others are wrong.

    --
    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 Mikko@21:1/5 to Richard Damon on Thu Aug 15 11:19:38 2024
    On 2024-08-14 04:04:23 +0000, Richard Damon said:

    On 8/13/24 11:48 PM, olcott wrote:
    On 8/13/2024 10:21 PM, Richard Damon wrote:
    On 8/13/24 10:38 PM, olcott wrote:
    On 8/13/2024 9:29 PM, Richard Damon wrote:
    On 8/13/24 8:52 PM, olcott wrote:
    void DDD()
    {
       HHH(DDD);
       return;
    }

    _DDD()
    [00002172] 55         push ebp      ; housekeeping
    [00002173] 8bec       mov ebp,esp   ; housekeeping
    [00002175] 6872210000 push 00002172 ; push DDD
    [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
    [0000217f] 83c404     add esp,+04
    [00002182] 5d         pop ebp
    [00002183] c3         ret
    Size in bytes:(0018) [00002183]

    A simulation of N instructions of DDD by HHH according to
    the semantics of the x86 language is necessarily correct.


    Nope, it is just the correct PARTIAL emulation of the first N
    instructions of DDD, and not of all of DDD,

    That is what I said dufuss.

    Nope. You didn't. I added clairifying words, pointing out why you claim
    is incorrect.

    For an emulation to be "correct" it must be complete, as partial
    emulations are only partially correct, so without the partial modifier,
    they are not correct.


    A complete emulation of one instruction is
    a complete emulation of one instruction






    A correct simulation of N instructions of DDD by HHH is
    sufficient to correctly predict the behavior of an unlimited
    simulation.

    Nope, if a HHH returns to its caller,

    *Try to show exactly how DDD emulated by HHH returns to its caller*
    (the first one doesn't even have a caller)
    Use the above machine language instructions to show this.


    Remember how English works:

    When you ask "How DDD emulated by HHH returns to its callers".

    Show the exact machine code trace of how DDD emulated
    by HHH (according to the semantics of the x86 language)
    reaches its own machine address 00002183

    No. The trace is to long, and since you HHH doesn't meet your
    requirements (since it isn't a pure function) you can't give me a
    compldte input to trace.

    The trace is regular enough that we could define a formal language for
    the trace and construct an analyzer program to detect deviations from
    x86 semnatics and hidden inputs.

    --
    Mikko

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mikko@21:1/5 to olcott on Thu Aug 15 13:26:57 2024
    On 2024-08-14 13:38:51 +0000, olcott said:

    On 8/14/2024 3:17 AM, Mikko wrote:
    On 2024-08-14 00:52:36 +0000, olcott said:

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

    In order to prove that the above specifies a non-halting behavour
    you must prove that HHH(DDD) does not terminate.


    That is the strawman error of reasoning.

    No, the word "strawman" means someting else.

    The focus of the post was to show that DDD emulated by HHH
    according to the semantics of the x86 language cannot possibly
    reach its own "return" instruction.

    By changing the subject you cheat.

    That is false. Everything you say is a valid topic for a reply.

    --
    Mikko

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mikko@21:1/5 to olcott on Thu Aug 15 13:22:16 2024
    On 2024-08-14 13:06:27 +0000, olcott said:

    On 8/14/2024 3:17 AM, Mikko wrote:
    On 2024-08-14 00:52:36 +0000, olcott said:

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

    In order to prove that the above specifies a non-halting behavour
    you must prove that HHH(DDD) does not terminate.

    Wrong.

    At least the proof that DDD does not terminate also proves as an
    intermedate result or an obvious corollary that HHH does not halt.

    Non-halting means that an infinite number of instructions can be
    executed without halting. That means that at least one instruction
    is executed infinitely many times as there are only finitely many
    instructions. But not instrunctions of DDD outside HHH is executed
    infinitely many times.

    --
    Mikko

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Terry@21:1/5 to joes on Thu Aug 15 18:31:27 2024
    On 15/08/2024 08:00, joes wrote:
    Am Wed, 14 Aug 2024 16:07:43 +0100 schrieb Mike Terry:
    On 14/08/2024 08:43, joes wrote:
    Am Tue, 13 Aug 2024 21:38:07 -0500 schrieb olcott:
    On 8/13/2024 9:29 PM, Richard Damon wrote:
    On 8/13/24 8:52 PM, olcott wrote:

    A simulation of N instructions of DDD by HHH according to the
    semantics of the x86 language is necessarily correct.
    Nope, it is just the correct PARTIAL emulation of the first N
    instructions of DDD, and not of all of DDD,
    That is what I said dufuss.
    You were trying to label an incomplete/partial/aborted simulation as
    correct.

    A correct simulation of N instructions of DDD by HHH is sufficient >>>>>> to correctly predict the behavior of an unlimited simulation.
    Nope, if a HHH returns to its caller,
    *Try to show exactly how DDD emulated by HHH returns to its caller*
    how *HHH* returns

    HHH simulates DDD enter the matrix
    DDD calls HHH(DDD) Fred: could be eliminated HHH simulates
    DDD
    second level
    DDD calls HHH(DDD) recursion detected
    HHH aborts, returns outside interference DDD halts
    voila
    HHH halts

    You're misunderstanding the scenario? If your simulated HHH aborts its
    simulation [line 5 above],
    then the outer level H would have aborted its identical simulation
    earlier. You know that, right?
    Of course. I made it only to illustrate one step in the paradoxical reasoning, as long as we're calling programs that do or don't abort
    the same.

    So... it seems that perhaps you agree on this one specific point: that when (some specific) HHH
    partially simulates its associated (specific) DDD, that SIMULATION does not get as far as simulating
    DDD returning? [Well, it did in your example above, but you seem to have agreed that was logically
    wrong.]

    For example, perhaps HHH never aborts so the simulation never terminates, or in the case of PO's HHH
    in halt7.c, HHH aborts its simulation before DDD gets as far as returning. Either way /the partial
    simulation/ does not proceed to a point where DDD returns...

    That's a completely different question from asking whether computation DDD() ever returns, which is
    what a halt decider must decide. You shouldn't feel that if you agree with the former, that you're
    also agreeing that DDD() never halts, or that "not halting is the right answer for HHH to give for
    input DDD" or any other PO nonsense!

    I'd just add that if you do agree with PO on this one specific point, why argue with him about it?
    Just agree and PO will soon move on to some completely ridiculous conclusion that surely would be
    more fun to argue with (assuming you enjoy arguing with PO :)).


    Mike.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Thu Aug 15 21:57:42 2024
    On 8/15/24 10:58 AM, olcott wrote:
    On 8/15/2024 3:19 AM, Mikko wrote:
    On 2024-08-14 04:04:23 +0000, Richard Damon said:

    On 8/13/24 11:48 PM, olcott wrote:
    On 8/13/2024 10:21 PM, Richard Damon wrote:
    On 8/13/24 10:38 PM, olcott wrote:
    On 8/13/2024 9:29 PM, Richard Damon wrote:
    On 8/13/24 8:52 PM, olcott wrote:
    void DDD()
    {
       HHH(DDD);
       return;
    }

    _DDD()
    [00002172] 55         push ebp      ; housekeeping >>>>>>>> [00002173] 8bec       mov ebp,esp   ; housekeeping
    [00002175] 6872210000 push 00002172 ; push DDD
    [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
    [0000217f] 83c404     add esp,+04
    [00002182] 5d         pop ebp
    [00002183] c3         ret
    Size in bytes:(0018) [00002183]

    A simulation of N instructions of DDD by HHH according to
    the semantics of the x86 language is necessarily correct.


    Nope, it is just the correct PARTIAL emulation of the first N
    instructions of DDD, and not of all of DDD,

    That is what I said dufuss.

    Nope. You didn't. I added clairifying words, pointing out why you
    claim is incorrect.

    For an emulation to be "correct" it must be complete, as partial
    emulations are only partially correct, so without the partial
    modifier, they are not correct.


    A complete emulation of one instruction is
    a complete emulation of one instruction






    A correct simulation of N instructions of DDD by HHH is
    sufficient to correctly predict the behavior of an unlimited
    simulation.

    Nope, if a HHH returns to its caller,

    *Try to show exactly how DDD emulated by HHH returns to its caller* >>>>>> (the first one doesn't even have a caller)
    Use the above machine language instructions to show this.


    Remember how English works:

    When you ask "How DDD emulated by HHH returns to its callers".

    Show the exact machine code trace of how DDD emulated
    by HHH (according to the semantics of the x86 language)
    reaches its own machine address 00002183

    No. The trace is to long, and since you HHH doesn't meet your
    requirements (since it isn't a pure function) you can't give me a
    compldte input to trace.

    The trace is regular enough that we could define a formal language for
    the trace and construct an analyzer program to detect deviations from
    x86 semnatics and hidden inputs.


    There are no deviations. The x86utm operating system is
    built from libx86emu that has had decades of development
    effort. HHH really does emulate itself emulating DDD.


    And then ignores that emulation, so it really didn't effectively emulate it.

    *This source-code proves it* https://github.com/plolcott/x86utm/blob/master/Halt7.c
    Mike seems to have the best understanding of that source-code.

    Amd it proves that HHH is *NOT* a "pure function" and thus doesn't even
    qualify to be a "decider".

    Sorry, but the simple inspection of the code proves that you have been
    lying about this the full time, and thus none of your proof that looks
    at that is valid.


    He might not yet understand that HHH does emulate itself
    emulating DDD. He could find out how HHH does this.

    HHH calls the x86utm operating system to create a new
    process context to emulate DDD. HHH emulates itself in
    the same process context. Its emulated self calls x86utm
    to create another process context to emulate its own
    DDD instance.


    And ignores the fact that the DDD that it is emulting (which includes
    the code of the HHH that it calls) only CONDITIONALLY emulates the next
    layer, and that it WILL abort its emulation (since it does the same as
    this HHH since it is the same code, or at least it would when you fix
    the impurity of the code) and thus HHH can not consider DDD to be
    non-halting.

    Of course, the fact that as has been pointed out, your HHH that you have
    worked on for all these years STILL fails to meet the basic requirements
    of being a pure function and thus isn't eligable to be a Decider in the
    first place.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Fri Aug 16 00:02:17 2024
    On 8/15/24 10:26 PM, olcott wrote:
    On 8/15/2024 8:57 PM, Richard Damon wrote:
    On 8/15/24 10:58 AM, olcott wrote:
    On 8/15/2024 3:19 AM, Mikko wrote:
    On 2024-08-14 04:04:23 +0000, Richard Damon said:

    On 8/13/24 11:48 PM, olcott wrote:
    On 8/13/2024 10:21 PM, Richard Damon wrote:
    On 8/13/24 10:38 PM, olcott wrote:
    On 8/13/2024 9:29 PM, Richard Damon wrote:
    On 8/13/24 8:52 PM, olcott wrote:
    void DDD()
    {
       HHH(DDD);
       return;
    }

    _DDD()
    [00002172] 55         push ebp      ; housekeeping >>>>>>>>>> [00002173] 8bec       mov ebp,esp   ; housekeeping >>>>>>>>>> [00002175] 6872210000 push 00002172 ; push DDD
    [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
    [0000217f] 83c404     add esp,+04
    [00002182] 5d         pop ebp
    [00002183] c3         ret
    Size in bytes:(0018) [00002183]

    A simulation of N instructions of DDD by HHH according to
    the semantics of the x86 language is necessarily correct.


    Nope, it is just the correct PARTIAL emulation of the first N >>>>>>>>> instructions of DDD, and not of all of DDD,

    That is what I said dufuss.

    Nope. You didn't. I added clairifying words, pointing out why you >>>>>>> claim is incorrect.

    For an emulation to be "correct" it must be complete, as partial >>>>>>> emulations are only partially correct, so without the partial
    modifier, they are not correct.


    A complete emulation of one instruction is
    a complete emulation of one instruction






    A correct simulation of N instructions of DDD by HHH is
    sufficient to correctly predict the behavior of an unlimited >>>>>>>>>> simulation.

    Nope, if a HHH returns to its caller,

    *Try to show exactly how DDD emulated by HHH returns to its caller* >>>>>>>> (the first one doesn't even have a caller)
    Use the above machine language instructions to show this.


    Remember how English works:

    When you ask "How DDD emulated by HHH returns to its callers".

    Show the exact machine code trace of how DDD emulated
    by HHH (according to the semantics of the x86 language)
    reaches its own machine address 00002183

    No. The trace is to long, and since you HHH doesn't meet your
    requirements (since it isn't a pure function) you can't give me a
    compldte input to trace.

    The trace is regular enough that we could define a formal language for >>>> the trace and construct an analyzer program to detect deviations from
    x86 semnatics and hidden inputs.


    There are no deviations. The x86utm operating system is
    built from libx86emu that has had decades of development
    effort. HHH really does emulate itself emulating DDD.


    And then ignores that emulation,

    counter-factual but you don't care.


    Then why does it say there were no conditional branches in the
    simulation of the code of the program "DDD" where there were in the
    simulation of the HHH that was called by DDD and thus part of the
    program DDD.

    Or, are you going to admit that you fail to understand the definition of
    a program, and thus your last two decades of work just went up in the
    smoke of error due to self-created ignorance.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From joes@21:1/5 to All on Fri Aug 16 07:13:33 2024
    Am Thu, 15 Aug 2024 23:20:06 -0500 schrieb olcott:
    On 8/15/2024 11:02 PM, Richard Damon wrote:
    On 8/15/24 10:26 PM, olcott wrote:
    On 8/15/2024 8:57 PM, Richard Damon wrote:
    On 8/15/24 10:58 AM, olcott wrote:
    On 8/15/2024 3:19 AM, Mikko wrote:
    On 2024-08-14 04:04:23 +0000, Richard Damon said:
    On 8/13/24 11:48 PM, olcott wrote:
    On 8/13/2024 10:21 PM, Richard Damon wrote:
    On 8/13/24 10:38 PM, olcott wrote:
    On 8/13/2024 9:29 PM, Richard Damon wrote:
    On 8/13/24 8:52 PM, olcott wrote:

    No. The trace is too long, and since you HHH doesn't meet your
    requirements (since it isn't a pure function) you can't give me a >>>>>>> compldte input to trace.

    The trace is regular enough that we could define a formal language >>>>>> for the trace and construct an analyzer program to detect
    deviations from x86 semnatics and hidden inputs.

    There are no deviations. The x86utm operating system is built from
    libx86emu that has had decades of development effort. HHH really
    does emulate itself emulating DDD.

    And then ignores that emulation,

    counter-factual but you don't care.

    Then why does it say there were no conditional branches in the
    simulation of the code of the program "DDD" where there were in the
    simulation of the HHH that was called by DDD and thus part of the
    program DDD.
    Never heard of dividing the program under test from the test program?
    HHH is reporting on the behavior of DDD.
    Only that is not possible here, because HHH is part of DDD by design.
    If you change the abort conditions on one of them, you break the
    recursive structure.

    --
    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 Mikko@21:1/5 to olcott on Fri Aug 16 11:57:43 2024
    On 2024-08-14 13:38:51 +0000, olcott said:

    On 8/14/2024 3:17 AM, Mikko wrote:
    On 2024-08-14 00:52:36 +0000, olcott said:

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

    In order to prove that the above specifies a non-halting behavour
    you must prove that HHH(DDD) does not terminate.

    That is the strawman error of reasoning.

    No, it is not. A "strawman" is a refutation (or an attempted refutation)
    of a claim that is falsely attributed to the opponent.

    --
    Mikko

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mikko@21:1/5 to olcott on Fri Aug 16 11:53:52 2024
    On 2024-08-15 15:25:07 +0000, olcott said:

    On 8/15/2024 5:22 AM, Mikko wrote:
    On 2024-08-14 13:06:27 +0000, olcott said:

    On 8/14/2024 3:17 AM, Mikko wrote:
    On 2024-08-14 00:52:36 +0000, olcott said:

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

    In order to prove that the above specifies a non-halting behavour
    you must prove that HHH(DDD) does not terminate.

    Wrong.

    At least the proof that DDD does not terminate also proves as an
    intermedate result or an obvious corollary that HHH does not halt.

    Non-halting means that an infinite number of instructions can be
    executed without halting. That means that at least one instruction
    is executed infinitely many times as there are only finitely many
    instructions. But not instrunctions of DDD outside HHH is executed
    infinitely many times.


    Wrong. Non-halting only means that when DDD is emulated
    according to the semantics of the x86 language and this
    emulation is unlimited that DDD would never reach its
    own "return" instruction.

    If what I said is wrong then what you said is wrong, too,
    as you say what I said.

    --
    Mikko

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mikko@21:1/5 to olcott on Fri Aug 16 11:59:33 2024
    On 2024-08-15 14:14:42 +0000, olcott said:

    On 8/15/2024 5:26 AM, Mikko wrote:
    On 2024-08-14 13:38:51 +0000, olcott said:

    On 8/14/2024 3:17 AM, Mikko wrote:
    On 2024-08-14 00:52:36 +0000, olcott said:

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

    In order to prove that the above specifies a non-halting behavour
    you must prove that HHH(DDD) does not terminate.


    That is the strawman error of reasoning.

    No, the word "strawman" means someting else.

    The focus of the post was to show that DDD emulated by HHH
    according to the semantics of the x86 language cannot possibly
    reach its own "return" instruction.

    By changing the subject you cheat.

    That is false. Everything you say is a valid topic for a reply.

    The focus of the post was to show that DDD emulated by HHH
    according to the semantics of the x86 language cannot possibly
    reach its own "return" instruction.

    The focus of your post.

    Whatever you say that does not directly address these exact
    words is construed as a dishonest dodge away from the point.

    You may construe whatever you want. That does not ressttrict others.

    --
    Mikko

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mikko@21:1/5 to olcott on Fri Aug 16 12:11:02 2024
    On 2024-08-16 04:20:06 +0000, olcott said:

    On 8/15/2024 11:02 PM, Richard Damon wrote:
    On 8/15/24 10:26 PM, olcott wrote:
    On 8/15/2024 8:57 PM, Richard Damon wrote:
    On 8/15/24 10:58 AM, olcott wrote:
    On 8/15/2024 3:19 AM, Mikko wrote:
    On 2024-08-14 04:04:23 +0000, Richard Damon said:

    On 8/13/24 11:48 PM, olcott wrote:
    On 8/13/2024 10:21 PM, Richard Damon wrote:
    On 8/13/24 10:38 PM, olcott wrote:
    On 8/13/2024 9:29 PM, Richard Damon wrote:
    On 8/13/24 8:52 PM, olcott wrote:
    void DDD()
    {
       HHH(DDD);
       return;
    }

    _DDD()
    [00002172] 55         push ebp      ; housekeeping >>>>>>>>>>>> [00002173] 8bec       mov ebp,esp   ; housekeeping >>>>>>>>>>>> [00002175] 6872210000 push 00002172 ; push DDD
    [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
    [0000217f] 83c404     add esp,+04
    [00002182] 5d         pop ebp
    [00002183] c3         ret
    Size in bytes:(0018) [00002183]

    A simulation of N instructions of DDD by HHH according to >>>>>>>>>>>> the semantics of the x86 language is necessarily correct. >>>>>>>>>>>>

    Nope, it is just the correct PARTIAL emulation of the first N >>>>>>>>>>> instructions of DDD, and not of all of DDD,

    That is what I said dufuss.

    Nope. You didn't. I added clairifying words, pointing out why you claim
    is incorrect.

    For an emulation to be "correct" it must be complete, as partial >>>>>>>>> emulations are only partially correct, so without the partial modifier,
    they are not correct.


    A complete emulation of one instruction is
    a complete emulation of one instruction






    A correct simulation of N instructions of DDD by HHH is >>>>>>>>>>>> sufficient to correctly predict the behavior of an unlimited >>>>>>>>>>>> simulation.

    Nope, if a HHH returns to its caller,

    *Try to show exactly how DDD emulated by HHH returns to its caller* >>>>>>>>>> (the first one doesn't even have a caller)
    Use the above machine language instructions to show this.


    Remember how English works:

    When you ask "How DDD emulated by HHH returns to its callers". >>>>>>>>
    Show the exact machine code trace of how DDD emulated
    by HHH (according to the semantics of the x86 language)
    reaches its own machine address 00002183

    No. The trace is to long, and since you HHH doesn't meet your
    requirements (since it isn't a pure function) you can't give me a >>>>>>> compldte input to trace.

    The trace is regular enough that we could define a formal language for >>>>>> the trace and construct an analyzer program to detect deviations from >>>>>> x86 semnatics and hidden inputs.


    There are no deviations. The x86utm operating system is
    built from libx86emu that has had decades of development
    effort. HHH really does emulate itself emulating DDD.


    And then ignores that emulation,

    counter-factual but you don't care.


    Then why does it say there were no conditional branches in the
    simulation of the code of the program "DDD" where there were in the
    simulation of the HHH that was called by DDD and thus part of the
    program DDD.

    Never heard of dividing the program under test from the test program?
    HHH is reporting on the behavior of DDD.

    I have worked with many differend kinds of testing of programs for many different purposes, and I have never heard anyone to say so or anything
    like that.

    --
    Mikko

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From joes@21:1/5 to All on Fri Aug 16 13:21:06 2024
    Am Fri, 16 Aug 2024 07:42:22 -0500 schrieb olcott:
    On 8/16/2024 3:53 AM, Mikko wrote:
    On 2024-08-15 15:25:07 +0000, olcott said:
    On 8/15/2024 5:22 AM, Mikko wrote:
    On 2024-08-14 13:06:27 +0000, olcott said:
    On 8/14/2024 3:17 AM, Mikko wrote:
    On 2024-08-14 00:52:36 +0000, olcott said:

    In order to prove that the above specifies a non-halting behavour
    you must prove that HHH(DDD) does not terminate.

    At least the proof that DDD does not terminate also proves as an
    intermedate result or an obvious corollary that HHH does not halt.
    Non-halting means that an infinite number of instructions can be
    executed without halting. That means that at least one instruction is
    executed infinitely many times as there are only finitely many
    instructions. But not instrunctions of DDD outside HHH is executed
    infinitely many times.

    Wrong. Non-halting only means that when DDD is emulated according to
    the semantics of the x86 language and this emulation is unlimited that
    DDD would never reach its own "return" instruction.

    If what I said is wrong then what you said is wrong, too,
    as you say what I said.

    *You are getting the computer science incorrectly*
    On 8/2/2024 11:32 PM, Jeff Barnett wrote:
    ...In some formulations, there are specific states
    defined as "halting states" and the machine only halts if either
    the start state is a halt state...
    ...these and many other definitions all have
    equivalent computing prowess...
    The "return" instruction is the halt state of DDD.
    It's kind of amazing to see you quote unrelated stuff.
    How does HHH not simulate DDD returning, while not executing the same instructions infinitely?

    --
    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 Richard Damon@21:1/5 to olcott on Fri Aug 16 10:18:39 2024
    On 8/16/24 8:42 AM, olcott wrote:
    On 8/16/2024 3:53 AM, Mikko wrote:
    On 2024-08-15 15:25:07 +0000, olcott said:

    On 8/15/2024 5:22 AM, Mikko wrote:
    On 2024-08-14 13:06:27 +0000, olcott said:

    On 8/14/2024 3:17 AM, Mikko wrote:
    On 2024-08-14 00:52:36 +0000, olcott said:

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

    In order to prove that the above specifies a non-halting behavour
    you must prove that HHH(DDD) does not terminate.

    Wrong.

    At least the proof that DDD does not terminate also proves as an
    intermedate result or an obvious corollary that HHH does not halt.

    Non-halting means that an infinite number of instructions can be
    executed without halting. That means that at least one instruction
    is executed infinitely many times as there are only finitely many
    instructions. But not instrunctions of DDD outside HHH is executed
    infinitely many times.


    Wrong. Non-halting only means that when DDD is emulated
    according to the semantics of the x86 language and this
    emulation is unlimited that DDD would never reach its
    own "return" instruction.

    If what I said is wrong then what you said is wrong, too,
    as you say what I said.


    *You are getting the computer science incorrectly*

    On 8/2/2024 11:32 PM, Jeff Barnett wrote:
    ...In some formulations, there are specific states
        defined as "halting states" and the machine only
        halts if either the start state is a halt state...

    ...these and many other definitions all have
        equivalent computing prowess...

    The "return" instruction is the halt state of DDD.


    Which DDD (the program) reaches if the HHH that it calls returns, which
    it will if any copy of that HHH given that same input does (or you are admitting you are lying about the properties of HHH).

    Remember, behavior as described above it based on the actual running (or COMPLETE simulation) of it, not on the partial simulation of it that HHH
    does.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mikko@21:1/5 to olcott on Sat Aug 17 10:54:25 2024
    On 2024-08-16 12:42:22 +0000, olcott said:

    On 8/16/2024 3:53 AM, Mikko wrote:
    On 2024-08-15 15:25:07 +0000, olcott said:

    On 8/15/2024 5:22 AM, Mikko wrote:
    On 2024-08-14 13:06:27 +0000, olcott said:

    On 8/14/2024 3:17 AM, Mikko wrote:
    On 2024-08-14 00:52:36 +0000, olcott said:

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

    In order to prove that the above specifies a non-halting behavour
    you must prove that HHH(DDD) does not terminate.

    Wrong.

    At least the proof that DDD does not terminate also proves as an
    intermedate result or an obvious corollary that HHH does not halt.

    Non-halting means that an infinite number of instructions can be
    executed without halting. That means that at least one instruction
    is executed infinitely many times as there are only finitely many
    instructions. But not instrunctions of DDD outside HHH is executed
    infinitely many times.


    Wrong. Non-halting only means that when DDD is emulated
    according to the semantics of the x86 language and this
    emulation is unlimited that DDD would never reach its
    own "return" instruction.

    If what I said is wrong then what you said is wrong, too,
    as you say what I said.


    *You are getting the computer science incorrectly*

    On 8/2/2024 11:32 PM, Jeff Barnett wrote:
    ...In some formulations, there are specific states
    defined as "halting states" and the machine only
    halts if either the start state is a halt state...

    These formulations have the problem that it is possible that
    a computation reaches a state where the computation shall not
    halt and cannot be continued. Therefore most authors prefer a
    simpler formulation (introduced by Post) where halting simply
    means impossibility to continue. For x86 processors the best
    definition is that a computation halts when the SP register
    gets a value that is greater than its value at the start of
    the computation (in x86 processors the stack grows downwards
    to smaller addresses).

    --
    Mikko

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