1. Forum
  2. Usenet
  3. COMP.THEORY

  • Re: No decider is accountable for the computation that itself is contai

    From joes@21:1/5 to All on Mon Jul 29 20:17:55 2024
    Am Mon, 29 Jul 2024 11:32:00 -0500 schrieb olcott:
    On 7/28/2024 3:40 AM, Mikko wrote:
    On 2024-07-27 14:21:50 +0000, olcott said:
    On 7/27/2024 2:46 AM, Mikko wrote:
    On 2024-07-26 16:28:43 +0000, olcott said:

    No decider is ever accountable for the behavior of the computation
    that itself is contained within.
    That claim is fully unjustified. How do you even define "accountable"
    in the context of computations, automata, and deciders?

    Halt deciders report the halt status on the basis of the behavior that a finite string input specifies.
    Which is constructed to be the same as the surrounding computation.

    Did you think that halt deciders report the halt status on some other
    basis?
    No, what do you think the basis was?

    Halt deciders are not allowed to report on the behavior of the actual computation that they themselves are contained within. They are only
    allowed to compute the mapping from input finite strings.
    What if the input is the same as the containing computation?

    --
    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 Tue Jul 30 07:24:28 2024
    Am Mon, 29 Jul 2024 15:32:44 -0500 schrieb olcott:
    On 7/29/2024 3:17 PM, joes wrote:
    Am Mon, 29 Jul 2024 11:32:00 -0500 schrieb olcott:
    On 7/28/2024 3:40 AM, Mikko wrote:
    On 2024-07-27 14:21:50 +0000, olcott said:
    On 7/27/2024 2:46 AM, Mikko wrote:
    On 2024-07-26 16:28:43 +0000, olcott said:

    Halt deciders are not allowed to report on the behavior of the actual
    computation that they themselves are contained within. They are only
    allowed to compute the mapping from input finite strings.
    What if the input is the same as the containing computation?
    It always is except in the case where the decider is reporting on the TM description that itself is contained within.
    I don't understand. "The input is not the same as the containing
    computation when deciding on the description of the containing
    computation"?

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fred. Zwarts@21:1/5 to All on Tue Jul 30 20:53:00 2024
    Op 30.jul.2024 om 18:24 schreef olcott:
    On 7/30/2024 2:24 AM, joes wrote:
    Am Mon, 29 Jul 2024 15:32:44 -0500 schrieb olcott:
    On 7/29/2024 3:17 PM, joes wrote:
    Am Mon, 29 Jul 2024 11:32:00 -0500 schrieb olcott:
    On 7/28/2024 3:40 AM, Mikko wrote:
    On 2024-07-27 14:21:50 +0000, olcott said:
    On 7/27/2024 2:46 AM, Mikko wrote:
    On 2024-07-26 16:28:43 +0000, olcott said:

    Halt deciders are not allowed to report on the behavior of the actual >>>>> computation that they themselves are contained within. They are only >>>>> allowed to compute the mapping from input finite strings.
    What if the input is the same as the containing computation?
    It always is except in the case where the decider is reporting on the TM >>> description that itself is contained within.

    I don't understand. "The input is not the same as the containing
    computation when deciding on the description of the containing
    computation"?


    void DDD()
    {
      HHH(DDD);
    }

    The behavior of the correct emulation of the x86 machine
    language input DDD to a emulating halt decider HHH is not
    the same as behavior of the direct execution of DDD when
    the x86 machine language of DDD is correctly emulated
    by emulating halt decider HHH that calls HHH(DDD) (itself).


    In fact, HHH cannot possibly simulate *itself* correctly. That is the difference. HHH deviates from the semantics of the x86 language by
    skipping the last few instructions of the simulation of itself.
    This incorrect simulation does not show the behaviour of DDD, but it
    shows the error of HHH.

    DDD is a misleading and unneeded complication. It is easy to eliminate DDD:

    int main() {
    return HHH(main);
    }

    This has the same problem. This proves that the problem is not in DDD,
    but in HHH, which halts when it aborts the simulation, but it decides
    that the simulation of itself does not halt.
    It shows that HHH cannot possibly simulate itself correctly.

    No matter how much olcott wants it to be correct, or how many times
    olcott repeats that it is correct, it does not change the fact that such
    a simulation is incorrect, because it is unable to reach the end of a
    halting program.
    Olcott's own claim that the simulated HHH does not reach its end
    confirms it. The trace he has shown also proves that HHH cannot reach
    the end of its own simulation. So, his own claims prove that it is true
    that HHH cannot possibly simulate itself up to the end, which makes the simulation incomplete and, therefore, incorrect.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From joes@21:1/5 to All on Tue Jul 30 19:52:34 2024
    Am Tue, 30 Jul 2024 11:24:35 -0500 schrieb olcott:
    On 7/30/2024 2:24 AM, joes wrote:
    Am Mon, 29 Jul 2024 15:32:44 -0500 schrieb olcott:
    On 7/29/2024 3:17 PM, joes wrote:
    Am Mon, 29 Jul 2024 11:32:00 -0500 schrieb olcott:
    On 7/28/2024 3:40 AM, Mikko wrote:
    On 2024-07-27 14:21:50 +0000, olcott said:
    On 7/27/2024 2:46 AM, Mikko wrote:
    On 2024-07-26 16:28:43 +0000, olcott said:

    Halt deciders are not allowed to report on the behavior of the
    actual computation that they themselves are contained within. They
    are only allowed to compute the mapping from input finite strings.
    What if the input is the same as the containing computation?
    It always is except in the case where the decider is reporting on the
    TM description that itself is contained within.

    I don't understand. "The input is not the same as the containing
    computation when deciding on the description of the containing
    computation"?
    I mean: is that an accurate paraphrase?

    An executing Turing machine is not allowed to report on its own
    behavior. Every decider is only allowed to report on the behavior that
    its finite string input specifies.
    And what happens when those are the same?

    --
    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 Tue Jul 30 21:09:09 2024
    Am Tue, 30 Jul 2024 15:13:34 -0500 schrieb olcott:
    On 7/30/2024 2:52 PM, joes wrote:
    Am Tue, 30 Jul 2024 11:24:35 -0500 schrieb olcott:
    On 7/30/2024 2:24 AM, joes wrote:
    Am Mon, 29 Jul 2024 15:32:44 -0500 schrieb olcott:
    On 7/29/2024 3:17 PM, joes wrote:
    Am Mon, 29 Jul 2024 11:32:00 -0500 schrieb olcott:
    On 7/28/2024 3:40 AM, Mikko wrote:
    On 2024-07-27 14:21:50 +0000, olcott said:
    On 7/27/2024 2:46 AM, Mikko wrote:
    On 2024-07-26 16:28:43 +0000, olcott said:

    Halt deciders are not allowed to report on the behavior of the
    actual computation that they themselves are contained within. They >>>>>>> are only allowed to compute the mapping from input finite strings. >>>>>> What if the input is the same as the containing computation?
    It always is except in the case where the decider is reporting on
    the TM description that itself is contained within.

    I don't understand. "The input is not the same as the containing
    computation when deciding on the description of the containing
    computation"?
    I mean: is that an accurate paraphrase?

    An executing Turing machine is not allowed to report on its own
    behavior. Every decider is only allowed to report on the behavior that
    its finite string input specifies.
    And what happens when those are the same?
    That is always the case except in the rare exception that I discovered
    where a simulating halt decider is simulating the input that calls
    itself.
    Always? Most TMs don't get themselves as input. OTOH that is one of
    the most interesting cases.
    The description of a TM specifies the behaviour of that machine
    when it is running.

    --
    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 Tue Jul 30 21:21:36 2024
    On 7/30/24 4:13 PM, olcott wrote:
    On 7/30/2024 2:52 PM, joes wrote:
    Am Tue, 30 Jul 2024 11:24:35 -0500 schrieb olcott:
    On 7/30/2024 2:24 AM, joes wrote:
    Am Mon, 29 Jul 2024 15:32:44 -0500 schrieb olcott:
    On 7/29/2024 3:17 PM, joes wrote:
    Am Mon, 29 Jul 2024 11:32:00 -0500 schrieb olcott:
    On 7/28/2024 3:40 AM, Mikko wrote:
    On 2024-07-27 14:21:50 +0000, olcott said:
    On 7/27/2024 2:46 AM, Mikko wrote:
    On 2024-07-26 16:28:43 +0000, olcott said:

    Halt deciders are not allowed to report on the behavior of the
    actual computation that they themselves are contained within. They >>>>>>> are only allowed to compute the mapping from input finite strings. >>>>>> What if the input is the same as the containing computation?
    It always is except in the case where the decider is reporting on the >>>>> TM description that itself is contained within.

    I don't understand. "The input is not the same as the containing
    computation when deciding on the description of the containing
    computation"?
    I mean: is that an accurate paraphrase?

    An executing Turing machine is not allowed to report on its own
    behavior. Every decider is only allowed to report on the behavior that
    its finite string input specifies.
    And what happens when those are the same?


    That is always the case except in the rare exception that I
    discovered where a simulating halt decider is simulating
    the input that calls itself.

    And where do you get that from? All I can see is that this shows that
    you don't beleive that definitions actually define the meaning of the
    words, but a just "guidelines" that you allow yourself to twist with
    your pathetic ignorant pathological LIES based on your reckless
    disregard for the actual truth of the definitions.


    Because for the last 90 years everyone besides me rejected
    the notion of a simulating halt decider out-of-hand without
    any review no one ever noticed this anomaly before.


    FALSE, which just shows your ignorance. Back when I was in school, the
    use of simulation in various forms as one method to determine if an
    input represented a halting or non-halting machine were discussed, and
    what sort of non-halting behavior they could catch, and even different
    ways to minimize the size of the machine doing the deciding.

    Of course, it was admitted that it couldn't solve all inputs, but only
    catch certain classes of non-halting behavior. So, it seems that your "research" on the topic has been quite flawe, or intenrionaly ignorant.

    after all, the rule of finding "repeated state" is a rule that comes out
    of the study of simulating Halt deciders as one method of detecting
    non-halting behavior (and that study defines the actual meaning of the
    term "repeating state" that shows non-halting behavior).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike Terry@21:1/5 to olcott on Wed Jul 31 03:13:12 2024
    On 30/07/2024 22:22, olcott wrote:
    On 7/30/2024 4:09 PM, joes wrote:
    Am Tue, 30 Jul 2024 15:13:34 -0500 schrieb olcott:
    On 7/30/2024 2:52 PM, joes wrote:
    Am Tue, 30 Jul 2024 11:24:35 -0500 schrieb olcott:
    On 7/30/2024 2:24 AM, joes wrote:
    Am Mon, 29 Jul 2024 15:32:44 -0500 schrieb olcott:
    On 7/29/2024 3:17 PM, joes wrote:
    Am Mon, 29 Jul 2024 11:32:00 -0500 schrieb olcott:
    On 7/28/2024 3:40 AM, Mikko wrote:
    On 2024-07-27 14:21:50 +0000, olcott said:
    On 7/27/2024 2:46 AM, Mikko wrote:
    On 2024-07-26 16:28:43 +0000, olcott said:

    Halt deciders are not allowed to report on the behavior of the >>>>>>>>> actual computation that they themselves are contained within. They >>>>>>>>> are only allowed to compute the mapping from input finite strings. >>>>>>>> What if the input is the same as the containing computation?
    It always is except in the case where the decider is reporting on >>>>>>> the TM description that itself is contained within.

    I don't understand. "The input is not the same as the containing
    computation when deciding on the description of the containing
    computation"?
    I mean: is that an accurate paraphrase?

    An executing Turing machine is not allowed to report on its own
    behavior. Every decider is only allowed to report on the behavior that >>>>> its finite string input specifies.
    And what happens when those are the same?

    That is always the case except in the rare exception that I discovered
    where a simulating halt decider is simulating the input that calls
    itself.

    Always? Most TMs don't get themselves as input. OTOH that is one of
    the most interesting cases.
    The description of a TM specifies the behaviour of that machine
    when it is running.


    The x86 code of DDD when correctly emulated by HHH according
    to the semantics of the x86 code of DDD and HHH does have
    different behavior that the directly executed DDD as a matter
    of verified fact for three years.

    People deny this as if a smash a Boston Cream pie in the face
    and they deny that there ever was any pie even while their
    voice is incoherent because they are talking through the pie
    smashed on their face.

    Hehe, when you go on like this I can't help thinking of "head crusher":

    <https://www.youtube.com/watch?v=8t4pmlHRokg>

    Mike.



    *I do not a more precise way to say this now*
    DDD is emulated by HHH according to the semantics of the
    x86 code of DDD and HHH. This does include a recursive call
    from DDD to HHH(DDD) that cannot possibly stop repeating
    unless HHH aborts its emulation of DDD.


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Tue Jul 30 23:18:59 2024
    On 7/30/24 10:41 PM, olcott wrote:
    On 7/30/2024 9:13 PM, Mike Terry wrote:
    On 30/07/2024 22:22, olcott wrote:
    On 7/30/2024 4:09 PM, joes wrote:
    Am Tue, 30 Jul 2024 15:13:34 -0500 schrieb olcott:
    On 7/30/2024 2:52 PM, joes wrote:
    Am Tue, 30 Jul 2024 11:24:35 -0500 schrieb olcott:
    On 7/30/2024 2:24 AM, joes wrote:
    Am Mon, 29 Jul 2024 15:32:44 -0500 schrieb olcott:
    On 7/29/2024 3:17 PM, joes wrote:
    Am Mon, 29 Jul 2024 11:32:00 -0500 schrieb olcott:
    On 7/28/2024 3:40 AM, Mikko wrote:
    On 2024-07-27 14:21:50 +0000, olcott said:
    On 7/27/2024 2:46 AM, Mikko wrote:
    On 2024-07-26 16:28:43 +0000, olcott said:

    Halt deciders are not allowed to report on the behavior of the >>>>>>>>>>> actual computation that they themselves are contained within. >>>>>>>>>>> They
    are only allowed to compute the mapping from input finite >>>>>>>>>>> strings.
    What if the input is the same as the containing computation? >>>>>>>>> It always is except in the case where the decider is reporting on >>>>>>>>> the TM description that itself is contained within.

    I don't understand. "The input is not the same as the containing >>>>>>>> computation when deciding on the description of the containing >>>>>>>> computation"?
    I mean: is that an accurate paraphrase?

    An executing Turing machine is not allowed to report on its own
    behavior. Every decider is only allowed to report on the behavior >>>>>>> that
    its finite string input specifies.
    And what happens when those are the same?

    That is always the case except in the rare exception that I discovered >>>>> where a simulating halt decider is simulating the input that calls
    itself.

    Always? Most TMs don't get themselves as input. OTOH that is one of
    the most interesting cases.
    The description of a TM specifies the behaviour of that machine
    when it is running.


    The x86 code of DDD when correctly emulated by HHH according
    to the semantics of the x86 code of DDD and HHH does have
    different behavior that the directly executed DDD as a matter
    of verified fact for three years.

    People deny this as if a smash a Boston Cream pie in the face
    and they deny that there ever was any pie even while their
    voice is incoherent because they are talking through the pie
    smashed on their face.

    Hehe, when you go on like this I can't help thinking of "head crusher":

    <https://www.youtube.com/watch?v=8t4pmlHRokg>

    Mike.


    It has always been ridiculously stupid to say that DDD
    is not correctly emulated by HHH because how the hell
    would would get to the first instruction of DDD if HHH
    did not correctly emulate DDD ???

    ILLOGICAL STATMENT.

    Doing part of something right doesn't mean you did all of it right,

    IF HHH can't get even start its emulation, that would be a very bad
    emulation,


    The same thing applies when DDD calls HHH(DDD).

    Which MUST be emulated as the instructions of HHH and NOT what you shpw
    below.

    Below just proves that you are lying.,


    Begin Local Halt Decider Simulation   Execution Trace Stored at:1138cc [00002172][001138bc][001138c0] 55         push ebp      ; housekeeping
    [00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; housekeeping
    [00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
    New slave_stack at:14e2ec
    [00002172][0015e2e4][0015e2e8] 55         push ebp      ; housekeeping
    [00002173][0015e2e4][0015e2e8] 8bec       mov ebp,esp   ; housekeeping
    [00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD [0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
    Local Halt Decider: Infinite Recursion Detected Simulation Stopped

    Is the real issue that no one here besides me has any clue
    about the x86 language and they are all just faking it?

    No, you are just PROVING that you are lying.


    I have no idea what you are saying and on this basis I am
    sure that you must be wrong?


    So you admit that if you don't understand something that means the other
    person is lying,

    That is just admitting that you are stupid AND a pathological liar.

    That you don't understand something doesn't make it wrong, but you using
    that as a basic to call something wrong proves YOU to be just a liar.

    Sorry, you are too stupid for you own good and are just sinking your
    reputation under a mile deep pile of your shitty lies.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fred. Zwarts@21:1/5 to All on Wed Jul 31 10:20:07 2024
    Op 30.jul.2024 om 22:08 schreef olcott:
    On 7/30/2024 1:53 PM, Fred. Zwarts wrote:
    Op 30.jul.2024 om 18:24 schreef olcott:
    On 7/30/2024 2:24 AM, joes wrote:
    Am Mon, 29 Jul 2024 15:32:44 -0500 schrieb olcott:
    On 7/29/2024 3:17 PM, joes wrote:
    Am Mon, 29 Jul 2024 11:32:00 -0500 schrieb olcott:
    On 7/28/2024 3:40 AM, Mikko wrote:
    On 2024-07-27 14:21:50 +0000, olcott said:
    On 7/27/2024 2:46 AM, Mikko wrote:
    On 2024-07-26 16:28:43 +0000, olcott said:

    Halt deciders are not allowed to report on the behavior of the
    actual
    computation that they themselves are contained within. They are only >>>>>>> allowed to compute the mapping from input finite strings.
    What if the input is the same as the containing computation?
    It always is except in the case where the decider is reporting on
    the TM
    description that itself is contained within.

    I don't understand. "The input is not the same as the containing
    computation when deciding on the description of the containing
    computation"?


    void DDD()
    {
       HHH(DDD);
    }

    The behavior of the correct emulation of the x86 machine
    language input DDD to a emulating halt decider HHH is not
    the same as behavior of the direct execution of DDD when
    the x86 machine language of DDD is correctly emulated
    by emulating halt decider HHH that calls HHH(DDD) (itself).


    In fact, HHH cannot possibly simulate *itself* correctly.

    I have proven that HHH does emulate itself emulating DDD
    according to the semantics that the x86 machine code specifies.

    Dreams are no substitute for logic proofs.
    HHH is violating the semantics of the x86 language by skipping the last
    few instructions of its simulation.
    No matter how much olcott wants it to be correct, or how many times
    olcott repeats that it is correct, it does not change the fact that such
    a simulation is incorrect, because it is unable to reach the end of a
    halting program.
    Olcott's own claim that the simulated HHH does not reach its end
    confirms it. The trace he has shown also proves that HHH cannot reach
    the end of its own simulation. So, his own claims prove that it is true
    that HHH cannot possibly simulate itself up to the end, which makes the simulation incomplete and, therefore, incorrect.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fred. Zwarts@21:1/5 to All on Wed Jul 31 10:23:19 2024
    Op 30.jul.2024 om 23:22 schreef olcott:
    On 7/30/2024 4:09 PM, joes wrote:
    Am Tue, 30 Jul 2024 15:13:34 -0500 schrieb olcott:
    On 7/30/2024 2:52 PM, joes wrote:
    Am Tue, 30 Jul 2024 11:24:35 -0500 schrieb olcott:
    On 7/30/2024 2:24 AM, joes wrote:
    Am Mon, 29 Jul 2024 15:32:44 -0500 schrieb olcott:
    On 7/29/2024 3:17 PM, joes wrote:
    Am Mon, 29 Jul 2024 11:32:00 -0500 schrieb olcott:
    On 7/28/2024 3:40 AM, Mikko wrote:
    On 2024-07-27 14:21:50 +0000, olcott said:
    On 7/27/2024 2:46 AM, Mikko wrote:
    On 2024-07-26 16:28:43 +0000, olcott said:

    Halt deciders are not allowed to report on the behavior of the >>>>>>>>> actual computation that they themselves are contained within. They >>>>>>>>> are only allowed to compute the mapping from input finite strings. >>>>>>>> What if the input is the same as the containing computation?
    It always is except in the case where the decider is reporting on >>>>>>> the TM description that itself is contained within.

    I don't understand. "The input is not the same as the containing
    computation when deciding on the description of the containing
    computation"?
    I mean: is that an accurate paraphrase?

    An executing Turing machine is not allowed to report on its own
    behavior. Every decider is only allowed to report on the behavior that >>>>> its finite string input specifies.
    And what happens when those are the same?

    That is always the case except in the rare exception that I discovered
    where a simulating halt decider is simulating the input that calls
    itself.

    Always? Most TMs don't get themselves as input. OTOH that is one of
    the most interesting cases.
    The description of a TM specifies the behaviour of that machine
    when it is running.


    The x86 code of DDD when correctly emulated by HHH according
    to the semantics of the x86 code of DDD and HHH does have
    different behavior that the directly executed DDD as a matter
    of verified fact for three years.

    People deny this as if a smash a Boston Cream pie in the face
    and they deny that there ever was any pie even while their
    voice is incoherent because they are talking through the pie
    smashed on their face.

    *I do not a more precise way to say this now*
    DDD is emulated by HHH according to the semantics of the
    x86 code of DDD and HHH. This does include a recursive call
    from DDD to HHH(DDD) that cannot possibly stop repeating
    unless HHH aborts its emulation of DDD.


    HHH violates the semantics of the x86 language by skipping the last few instructions of a halting program. But olcott keeps dreaming of an
    infinite recursion that does not stop.
    Dreams are no substitute for logic proofs.
    No matter how much olcott wants it to be correct, or how many times
    olcott repeats that it is correct, it does not change the fact that such
    a simulation is incorrect, because it is unable to reach the end of a
    halting program.
    Olcott's own claim that the simulated HHH does not reach its end
    confirms it. The trace he has shown also proves that HHH cannot reach
    the end of its own simulation. So, his own claims prove that it is true
    that HHH cannot possibly simulate itself up to the end, which makes the simulation incomplete and, therefore, incorrect.



    --
    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 Fred. Zwarts@21:1/5 to All on Wed Jul 31 10:32:59 2024
    Op 31.jul.2024 om 04:41 schreef olcott:
    On 7/30/2024 9:13 PM, Mike Terry wrote:
    On 30/07/2024 22:22, olcott wrote:
    On 7/30/2024 4:09 PM, joes wrote:
    Am Tue, 30 Jul 2024 15:13:34 -0500 schrieb olcott:
    On 7/30/2024 2:52 PM, joes wrote:
    Am Tue, 30 Jul 2024 11:24:35 -0500 schrieb olcott:
    On 7/30/2024 2:24 AM, joes wrote:
    Am Mon, 29 Jul 2024 15:32:44 -0500 schrieb olcott:
    On 7/29/2024 3:17 PM, joes wrote:
    Am Mon, 29 Jul 2024 11:32:00 -0500 schrieb olcott:
    On 7/28/2024 3:40 AM, Mikko wrote:
    On 2024-07-27 14:21:50 +0000, olcott said:
    On 7/27/2024 2:46 AM, Mikko wrote:
    On 2024-07-26 16:28:43 +0000, olcott said:

    Halt deciders are not allowed to report on the behavior of the >>>>>>>>>>> actual computation that they themselves are contained within. >>>>>>>>>>> They
    are only allowed to compute the mapping from input finite >>>>>>>>>>> strings.
    What if the input is the same as the containing computation? >>>>>>>>> It always is except in the case where the decider is reporting on >>>>>>>>> the TM description that itself is contained within.

    I don't understand. "The input is not the same as the containing >>>>>>>> computation when deciding on the description of the containing >>>>>>>> computation"?
    I mean: is that an accurate paraphrase?

    An executing Turing machine is not allowed to report on its own
    behavior. Every decider is only allowed to report on the behavior >>>>>>> that
    its finite string input specifies.
    And what happens when those are the same?

    That is always the case except in the rare exception that I discovered >>>>> where a simulating halt decider is simulating the input that calls
    itself.

    Always? Most TMs don't get themselves as input. OTOH that is one of
    the most interesting cases.
    The description of a TM specifies the behaviour of that machine
    when it is running.


    The x86 code of DDD when correctly emulated by HHH according
    to the semantics of the x86 code of DDD and HHH does have
    different behavior that the directly executed DDD as a matter
    of verified fact for three years.

    People deny this as if a smash a Boston Cream pie in the face
    and they deny that there ever was any pie even while their
    voice is incoherent because they are talking through the pie
    smashed on their face.

    Hehe, when you go on like this I can't help thinking of "head crusher":

    <https://www.youtube.com/watch?v=8t4pmlHRokg>

    Mike.


    It has always been ridiculously stupid to say that DDD
    is not correctly emulated by HHH because how the hell
    would would get to the first instruction of DDD if HHH
    did not correctly emulate DDD ???

    The same thing applies when DDD calls HHH(DDD).

    Begin Local Halt Decider Simulation   Execution Trace Stored at:1138cc [00002172][001138bc][001138c0] 55         push ebp      ; housekeeping
    [00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; housekeeping
    [00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
    New slave_stack at:14e2ec
    [00002172][0015e2e4][0015e2e8] 55         push ebp      ; housekeeping
    [00002173][0015e2e4][0015e2e8] 8bec       mov ebp,esp   ; housekeeping
    [00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD [0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
    Local Halt Decider: Infinite Recursion Detected Simulation Stopped

    Is the real issue that no one here besides me has any clue
    about the x86 language and they are all just faking it?

    I have no idea what you are saying and on this basis I am
    sure that you must be wrong?


    You have no idea, because it seems to be over your head.

    When are you going to learn x86?
    The above code does not show any x86 instruction that bring the flow of
    the simulation back to 00002172.
    In addition, the call to 00000015d2 is not followed by the instruction
    at 00000015d2, as required by x86.
    Probably, you are hiding these instructions on purpose, because it would
    reveal the conditional branch instruction in HHH.
    Finally, HHH skips the last few instructions of a halting program, which
    is also against the semantics of the x86 language.
    All your talk about x86 is just word salad.

    HHH cannot possibly simulate itself correctly.
    No matter how much olcott wants it to be correct, or how many times
    olcott repeats that it is correct, it does not change the fact that such
    a simulation is incorrect, because it is unable to reach the end of a
    halting program.

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