• Re: Refuting the HP proofs (adapted for software engineers)[ members of

    From olcott@21:1/5 to Mike Terry on Tue Jun 7 20:04:26 2022
    XPost: comp.theory, sci.logic, sci.math

    On 6/7/2022 7:05 PM, Mike Terry wrote:
    On 07/06/2022 21:51, Mr Flibble wrote:
    On Tue, 7 Jun 2022 15:34:13 -0500
    olcott <NoOne@NoWhere.com> wrote:

    <..snip..>

    How many times do I have to say this before you notice that I said it
    at least once? H (in the current process) always creates a new
    process context to emulate its its input with an x86 emulator.

    I will have to take your word for it as you refuse to publish source
    code. Why not just stick your project on GitHub? Open source is de
    rigueur these days. What are you trying to hide?

    If a new process context is made then how is nested simulation
    detected?

    The code in x86utm.exe (his emulator) that emulates individual
    instructions also updates a global trace table, making it accessible to
    the emulated code.  So every instruction and any (nested, nested(nested) etc.) simulated instructions ALL get merged together in this one global trace.

    I imagine the global trace table to be much like the printed traces that
    PO posts over and over.  If YOU can recognise some pattern in those
    printed traces, then logically H can spot that same pattern in the
    global trace, as the info in both cases is more or less the same.


    When a UTM simulates TM description
    that invokes a UTM that simulates a TM description
    that invokes a UTM that simulates a TM description
    that invokes a UTM that simulates a TM description
    that invokes a UTM that simulates a TM description

    All of this whole process is data belongs to the first UTM, thus global
    data is not needed and the whole process is a computable function of the original inputs to the outermost UTM.

    [Above is my best guess, based on previous PO answers before you were interested.]

    I assume the data segment of each process is private...

    PO said "new process context.." and that would imply each has its own
    address space, and that is obviously how simulation is SUPPOSED to work
    (like a TM would perform) - so your assumption is totally reasonable!

    My unlimited nested simulations could not function properly if I did not
    know all of the details of how to do this.

    But you've made the basic mistake of assuming PO knows what a "process"
    is - PO is not a software engineer or computer scientist, although he
    does his utmost to give that impression!

    Anyhow, each PO-simulation is like a single-stepped thread within a
    SINGLE shared address space, so any globals in his H are shared by all
    his "independent" simulations.

    [Above is based on previous PO answers before you were interested.]

    Mike.


    --
    Copyright 2022 Pete Olcott

    "Talent hits a target no one else can hit;
    Genius hits a target no one else can see."
    Arthur Schopenhauer

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Tue Jun 7 22:45:08 2022
    XPost: comp.theory, sci.logic, sci.math

    On 6/7/22 9:04 PM, olcott wrote:
    On 6/7/2022 7:05 PM, Mike Terry wrote:
    On 07/06/2022 21:51, Mr Flibble wrote:
    On Tue, 7 Jun 2022 15:34:13 -0500
    olcott <NoOne@NoWhere.com> wrote:

    <..snip..>

    How many times do I have to say this before you notice that I said it
    at least once? H (in the current process) always creates a new
    process context to emulate its its input with an x86 emulator.

    I will have to take your word for it as you refuse to publish source
    code. Why not just stick your project on GitHub? Open source is de
    rigueur these days. What are you trying to hide?

    If a new process context is made then how is nested simulation
    detected?

    The code in x86utm.exe (his emulator) that emulates individual
    instructions also updates a global trace table, making it accessible
    to the emulated code.  So every instruction and any (nested,
    nested(nested) etc.) simulated instructions ALL get merged together in
    this one global trace.

    I imagine the global trace table to be much like the printed traces
    that PO posts over and over.  If YOU can recognise some pattern in
    those printed traces, then logically H can spot that same pattern in
    the global trace, as the info in both cases is more or less the same.


    When a UTM simulates TM description
    that invokes a UTM that simulates a TM description

    Nope, it invoke a copy of H that simulates its input and then abort is.

    that invokes a UTM that simulates a TM description
    that invokes a UTM that simulates a TM description
    that invokes a UTM that simulates a TM description

    This appears to be a flaw in your whole system design, you P changes to
    call as H whatever you try to use to simulate it.

    P needs to call the H that this P is designed to refute, and no others.

    Remember, You need to pick *A* H that you are going to claim is a
    correct decider, then you make *A* P based on that one, and run the
    descion and test on THOSE SPECIIFIC machines.


    All of this whole process is data belongs to the first UTM, thus global
    data is not needed and the whole process is a computable function of the original inputs to the outermost UTM.

    ????

    The input to the UTM is a description of a P that calls the H that you
    claim is correct in aborting its simulation of the P built on it.

    That UTM will simulate that input and generate the exact same results as running that P.

    That emulation will show the first 7 instructions of P, then the call to
    H, and then H doing its emulations and eventually aborting its emulaton
    and returning the 0 to P and P halting.

    If the H doesn't do this, then your H never answered H(P,P) as 0, and
    your whole premise is false, and shown to be a LIE.


    [Above is my best guess, based on previous PO answers before you were
    interested.]

    I assume the data segment of each process is private...

    PO said "new process context.." and that would imply each has its own
    address space, and that is obviously how simulation is SUPPOSED to
    work (like a TM would perform) - so your assumption is totally
    reasonable!

    My unlimited nested simulations could not function properly if I did not
    know all of the details of how to do this.

    Then why do you think the UTM sees another UTM when it should see an H.

    Remember, your LIE that the test was to REPLACE H with a UTM has been discredited, or are you still claiming that is what needs to be done,
    even though it doesn't match the test you define?

    Or, do you not understand that the representation of P includes
    EVERYTHING needed to run it, and thus does include the copy of H that it
    calls, so it doesn't change when we give that input to the UTM?


    But you've made the basic mistake of assuming PO knows what a
    "process" is - PO is not a software engineer or computer scientist,
    although he does his utmost to give that impression!

    Anyhow, each PO-simulation is like a single-stepped thread within a
    SINGLE shared address space, so any globals in his H are shared by all
    his "independent" simulations.

    [Above is based on previous PO answers before you were interested.]

    Mike.



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