• Re: Liar detector: Peter Olcott lies

    From Richard Damon@21:1/5 to olcott on Mon Jul 8 19:26:29 2024
    XPost: sci.logic

    On 7/8/24 11:24 AM, olcott wrote:
    On 7/8/2024 10:08 AM, joes wrote:
    Am Mon, 08 Jul 2024 10:04:37 -0500 schrieb olcott:
    On 7/8/2024 9:25 AM, Fred. Zwarts wrote:
    Op 07.jul.2024 om 15:46 schreef olcott:

    Correctly is measured by the semantics of the x86 language.
    This specifies that when DDD is correctly simulated by HHH calls
    emulated HHH(DDD) that this call cannot return.
    Yes. This shows that the simulation is incorrect.

    Similarly, HHH cannot possibly simulate itself correctly, no matter how >>>> much you want it to be correct,
    Where correct is understood to be what-ever-the-Hell that the machine
    code of DDD specifies within the semantics of the x86 language then:


    _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 correctly simulated by any pure function x86 emulator HHH
    that aborts its emulation at some point calls HHH(DDD) then it is
    correctly understood that this call cannot possibly return.

    An aborted simulation is not correct.


    It turns out the the #1 best selling author of theory of computation textbooks is not wrong when he agreed with my verbatim words.

    Which you don't understand what they mean. Remember, you need to go by
    HIS definition when you ask him about something he is an expert on.

    It is a LIE to try to claim any other.


    https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X

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

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

    On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
    I don't think that is the shell game.  PO really /has/ an H (it's
    trivial to do for this one case) that correctly determines that P(P) *would* never stop running *unless* aborted.
    ...
    But H determines (correctly) that D would not halt if it were not halted.  That much is a truism.

    *Proves that Ben agreed that the criteria has been met*
    Correct is certainly not screwball misconceptions that contradict the
    above.


    Ben failed to understand that professor Sipser was correct
    about what meeting the criteria entails.

    No, YOU fail to understand what Professor Sipser criteria means.

    Correct Simulation exactly matches the actual behavior of the program
    the input represents, which means a simulatation that doesn't "stop"
    except by reaching the final state.


    Ben thought that H must report on the behavior of D after
    H aborts its simulation before it aborts this simulation.

    Because he is right.


    This is analogous to needing groceries and saying that you
    do not need groceries before you get more groceries.


    No, it is analogous to saying a lead weight will hit the ground when it
    is release from a foot directly above the ground.

    The behavior of DDD (and HHH) is FULLY DEFINED AND FIXED by the
    definition of HHH. So, if HHH aborts its simulation and returns to its
    caller main, it does so to DDD too, making DDD halt.

    You confuse the actual Behavior of DDD, with the partial observation of
    it by HHH. Once HHH "lets go" of that behavior by stopping its
    simulation, it don't know, and can't affect that behavior any more.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Wed Jul 10 20:01:50 2024
    On 7/10/24 9:37 AM, olcott wrote:
    On 7/10/2024 2:18 AM, Mikko wrote:
    On 2024-07-09 14:14:16 +0000, olcott said:

    On 7/9/2024 1:14 AM, Mikko wrote:
    On 2024-07-08 17:36:58 +0000, olcott said:

    On 7/8/2024 11:16 AM, Fred. Zwarts wrote:
    Op 08.jul.2024 om 18:07 schreef olcott:

    Try to show how infinity is one cycle too soon.

    You believe that two equals infinity.

    void Infinite_Loop()
    {
       HERE: goto HERE;
    }

    void Infinite_Recursion()
    {
       Infinite_Recursion();
    }

    void DDD()
    {
       HHH(DDD);
    }

    Two cycles is enough to correctly determine that none
    of the above functions correctly emulated by HHH can
    possibly halt.

    That you don't see this is ignorance or deception.

    There is an important detail that determines whether an infinite
    execution can be inferred. That is best illustrated by the following
    examples:

    void Finite_Loop()
    {
      int x = 10000;
    HERE:
      if (x > 0) {
        x--;
        goto HERE;
      }
    }

    void Finite_Recursion(int n)
    {
      if (n > 0) {
        Finite_Recursion(n + 1);
      }
    }

    void DDD()
    {
      HHH(DDD); // HHH detects recursive simulation and then simulates
    no more
    }

    The important difference is that in my examples there is a conditional >>>> instruction that can (and does) prevent infinite exectuion.


    When we ask:
    Does the call from DDD emulated by HHH to HHH(DDD) return?

    Why would anyone ask that? A question should make clear its topic.
    Instead one could ask whether HHH can fully emulate DDD if that is
    what one wants to know. Or one may think that HHH and DDD are so
    unimteresting that there is no point to ask anyting about them.


    A correct emulator can correctly any correct x86 instructions.
    When it emulates non-halting code then itself does not halt.


    Right, so if the input is non-halting a correct emulation of it can not
    halt, and thus HHH can not do both a correct emulation of the input and
    say the input is non-halting. That is just a contradiction of terms.

    If HHH does abort its emulation, it no longer did a correct emulation
    and thus lost the ability to show that its input was non-halting. The
    only input you have shown to be non-halting is the input based on the non-aborting HHH, but that doesn't answer, and its DDD is DIFFERENT than
    the others, as DDD INCLUDES the HHH that it is calling. (something you
    try to gloss over as it proves you wrong).

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