1. Forum
  2. Usenet
  3. COMP.THEORY

  • Re: Google [x86utm operating system] --- Foundational false assumption

    From Fred. Zwarts@21:1/5 to All on Tue Aug 12 12:35:06 2025
    Op 12.aug.2025 om 07:01 schreef olcott:
    On 8/11/2025 10:51 PM, dbush wrote:
    On 8/11/2025 11:49 PM, olcott wrote:
    On 8/11/2025 10:42 PM, dbush wrote:
    On 8/11/2025 11:39 PM, olcott wrote:

    M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qy
    M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn

    No. the behavior specified by the input to M.H ⟨M⟩ ⟨M⟩

    i.e. finite string ⟨M⟩ which is defined to be a description of
    algorithm M, proven to be valid by UTM ⟨M⟩ ⟨M⟩ having the exact same
    behavior as M ⟨M⟩

    is provably different behavior than the behavior of
    M applied to ⟨M⟩.


    False, as shown above.

    So you do not understand that M.H ⟨M⟩ ⟨M⟩
    repeats recursively simulating itself?


    Only finitely, as the simulation UTM ⟨M⟩ ⟨M⟩ is exactly the same as >> the simulation M.H ⟨M⟩ ⟨M⟩ up to the point that M.H aborts, proving >> that algorithm M halts.

    M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qy
    M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn
    UTM ⟨M⟩ ⟨M⟩ has the same behavior as M ⟨M⟩
    and different behavior than M.H ⟨M⟩ ⟨M⟩.


    As usual repeated incorrect claims without evidence.
    The same behaviour is specified, but M.H fails to do the correct
    simulation up to the end. Therefore, the specified behaviour is not
    different, but M.H fails to follow the specified behaviour. It
    prematurely aborts one cycle before it would reach the final halt state.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fred. Zwarts@21:1/5 to All on Tue Aug 12 12:31:32 2025
    Op 12.aug.2025 om 06:00 schreef olcott:
    On 8/11/2025 10:51 PM, dbush wrote:
    On 8/11/2025 11:49 PM, olcott wrote:
    On 8/11/2025 10:42 PM, dbush wrote:
    On 8/11/2025 11:39 PM, olcott wrote:
    On 8/11/2025 10:29 PM, dbush wrote:
    On 8/11/2025 11:25 PM, olcott wrote:
    On 8/11/2025 10:19 PM, dbush wrote:
    On 8/11/2025 11:13 PM, olcott wrote:
    On 8/11/2025 9:54 PM, dbush wrote:
    On 8/11/2025 10:28 PM, olcott wrote:
    On 8/11/2025 9:12 PM, dbush wrote:
    On 8/11/2025 10:07 PM, olcott wrote:
    On 8/11/2025 8:57 PM, dbush wrote:
    On 8/11/2025 9:36 PM, olcott wrote:

    Because no Turing machine ever takes another
    Turing machine as an input no Turing machine can >>>>>>>>>>>>>>> directly compute the mapping from an input that
    is not in its domain.

    Therefore Turing machines can't do arithmetic because no >>>>>>>>>>>>>> Turing machine can take an actual number as input. >>>>>>>>>>>>>>
    Agreed?
    Finite string representations of numbers always behave >>>>>>>>>>>>> exactly the same way as if they were numbers.

    Finite string representations of Turing Machines do
    not always behave exactly the same way as the machine >>>>>>>>>>>>> in one single exceptional case that no one ever noticed >>>>>>>>>>>>> before:

    Which is just another way of saying the halting function is >>>>>>>>>>>> not a computable function, as Linz and others have proved >>>>>>>>>>>> and as you have *explicitly* agreed is correct.

    *No it is not another way of saying that*

    It is a way of saying that the halting function
    is not computable because

    Assuming it is causes contradictions.

    The halting problem causes no contradiction when
    it is understood that M.H ⟨M⟩ ⟨M⟩ correctly reports
    on the actual behavior of its actual input.

    In other words, H isn't giving the answer required by the
    specification and therefore doesn't meet the definition of a
    total halt decider / termination analyzer.


    When the spec requires reporting on a non-input
    and ignores reporting on an input then we know
    that spec is wrong.

    In other words Turning machines can't add 2 + 2 because the number >>>>>> 2 is a non-input, so any specification for a Turing machine to
    perform addition must be wrong.

    Agreed?

    M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qy
    M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn

    No. the behavior specified by the input to M.H ⟨M⟩ ⟨M⟩

    i.e. finite string ⟨M⟩ which is defined to be a description of
    algorithm M, proven to be valid by UTM ⟨M⟩ ⟨M⟩ having the exact same
    behavior as M ⟨M⟩

    is provably different behavior than the behavior of
    M applied to ⟨M⟩.


    False, as shown above.

    So you do not understand that M.H ⟨M⟩ ⟨M⟩
    repeats recursively simulating itself?


    Only finitely, as the simulation UTM ⟨M⟩ ⟨M⟩ is exactly the same as >> the simulation M.H ⟨M⟩ ⟨M⟩ up to the point that M.H aborts, proving >> that algorithm M halts.

    I have proven that to be factually incorrect
    numerous times on the basis of HHH(DDD) and HHH1(DDD).

    As usual incorrect claims without evidence. There never was a proof.


    HHH simulates DD then simulates an instance of itself
    that cannot possibly return.

    HHH1 simulates DD then simulates an instance of HHH
    that does return.
    That is your straw man. That HHH fails to reach the final halt state is
    not a proof that such a final halt state does not exist. HHH closes its
    eyes with a premature abort, when one cycle later the final halt state
    would be reached. Therefore, HHH does not see the final halt state that
    is specified in the input. You programmed your attitude in HHH: close
    your eyes and pretend that what your do not see does not exist.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Tue Aug 12 07:21:56 2025
    On 8/11/25 9:36 PM, olcott wrote:
    On 8/11/2025 2:04 PM, dbush wrote:
    On 8/11/2025 3:00 PM, olcott wrote:
    On 8/11/2025 1:51 PM, dbush wrote:
    On 8/11/2025 2:50 PM, olcott wrote:
    On 8/11/2025 1:45 PM, dbush wrote:
    On 8/11/2025 2:40 PM, olcott wrote:
    On 8/11/2025 1:33 PM, Richard Heathfield wrote:
    On 11/08/2025 18:48, olcott wrote:
    On 8/11/2025 11:42 AM, Richard Heathfield wrote:
    On 11/08/2025 17:29, olcott wrote:

    <snip>


    I have proven that DD correctly simulated by HHH

    No, you haven't. You have asserted that the simulation is
    correct, but we all know that it derives a different result >>>>>>>>>> from that produced by direct execution, and therefore we all >>>>>>>>>> know that the simulation is not correct.

    You can only fully know that your assumption is incorrect
    when you notice that no specific error exists.

    The specific error is that you get the wrong answer.
    It is incorrect to say it *is* a wrong answer until after
    a specific error in the basis of this answer is found.

    It's the wrong answer because it doesn't meet the required
    specification:


    That merely presumes that the required specification
    is correct.


    It's correct because I want to know if any arbitrary algorithm X
    with input Y will halt when executed directly.

    Likewise I want to know the radius of a square circle
    that has a length of 2.0 of one of its equal length
    four sides.

    The difference is that every algorithm X with input Y either halts or
    does not halt when executed directly, so there is a correct answer in
    all cases.


    Because no Turing machine ever takes another
    Turing machine as an input no Turing machine can
    directly compute the mapping from an input that
    is not in its domain.

    But no Turing Machine ever takes "a number" as an input, only the representation of a number, but they still can do "arithmatic".

    Thus, they can take the representation of a Turing Machine, and be
    allowed to ask about its behavior.


    In all but one case input ⟨M⟩ to simulating halt
    decider H has the exact same behavior machine M.

    No, there is no exception, that is just a lie from your mind.

    YOu show it is a lie, by the fact you can't show a source for that, or a
    proof of it.

    It just comes from your unprincipled guesses about how programs work,
    that you lie and call based on "first-principled", but it wss based on
    the actual principles, so is just a lie.


    M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qy
    M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn
    (a) M copies its input ⟨M⟩
    (b) M invokes M.H ⟨M⟩ ⟨M⟩
    (c) M.H simulates ⟨M⟩ ⟨M⟩

    When H is embedded within M then the behavior of
    ⟨M⟩ ⟨M⟩ simulated by M.H cannot possibly reach a final
    halt state, even if there is no loop trick at the end.

    And if H tries to do that correct simulation, it just becomes
    non-halting itself and not a decider, but you are right, THAT version of
    M given its own representation does halt,

    But if H tries to abort, then, since the input is built on that final H
    decided on, it ALSO aborts its simulation, and this DIFFERENT version of
    M, given the different input, its own representation, does halt, and H
    is just wrong.

    You are just so stupid, that you forget the definition of M, and that it changes depending on your definition of H.


    The halting problem definition assumes that this case
    does not exist. Thus they used the short-hand that
    H applied to ⟨M⟩ ⟨M⟩ is reporting on M applied to ⟨M⟩.


    No, that case just makes H not a decider, so it can't be a Halt Decider.

    Your problem is you don't know what a program is and confuse the
    template of the problem, with the program that template creates for each decider it makes wrong. The problem uses the program as the input, not
    the template, and thus your whole argument is a category error based on
    your lie about what M is.

    Sorry, you have shown that you are so stupid you can waste years not
    learning the basics of the material you are claiming to work on.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Tue Aug 12 07:29:35 2025
    On 8/12/25 1:01 AM, olcott wrote:
    On 8/11/2025 10:51 PM, dbush wrote:
    On 8/11/2025 11:49 PM, olcott wrote:
    On 8/11/2025 10:42 PM, dbush wrote:
    On 8/11/2025 11:39 PM, olcott wrote:

    M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qy
    M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn

    No. the behavior specified by the input to M.H ⟨M⟩ ⟨M⟩

    i.e. finite string ⟨M⟩ which is defined to be a description of
    algorithm M, proven to be valid by UTM ⟨M⟩ ⟨M⟩ having the exact same
    behavior as M ⟨M⟩

    is provably different behavior than the behavior of
    M applied to ⟨M⟩.


    False, as shown above.

    So you do not understand that M.H ⟨M⟩ ⟨M⟩
    repeats recursively simulating itself?


    Only finitely, as the simulation UTM ⟨M⟩ ⟨M⟩ is exactly the same as >> the simulation M.H ⟨M⟩ ⟨M⟩ up to the point that M.H aborts, proving >> that algorithm M halts.

    M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qy
    M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn
    UTM ⟨M⟩ ⟨M⟩ has the same behavior as M ⟨M⟩
    and different behavior than M.H ⟨M⟩ ⟨M⟩.


    Which shows that M.H didn't get the right answer, and you can't use the
    concept of a "correct simulation by H" as a definition of the behavior
    of its input, as it doesn't DO a correct simulation.

    Sorry, you are just proving how baseless your logic is and how much you
    just base your arguments on lies.

    This just shows that you are just a damned pathological liar.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Tue Aug 12 07:26:57 2025
    On 8/12/25 12:00 AM, olcott wrote:
    On 8/11/2025 10:51 PM, dbush wrote:
    On 8/11/2025 11:49 PM, olcott wrote:
    On 8/11/2025 10:42 PM, dbush wrote:
    On 8/11/2025 11:39 PM, olcott wrote:
    On 8/11/2025 10:29 PM, dbush wrote:
    On 8/11/2025 11:25 PM, olcott wrote:
    On 8/11/2025 10:19 PM, dbush wrote:
    On 8/11/2025 11:13 PM, olcott wrote:
    On 8/11/2025 9:54 PM, dbush wrote:
    On 8/11/2025 10:28 PM, olcott wrote:
    On 8/11/2025 9:12 PM, dbush wrote:
    On 8/11/2025 10:07 PM, olcott wrote:
    On 8/11/2025 8:57 PM, dbush wrote:
    On 8/11/2025 9:36 PM, olcott wrote:

    Because no Turing machine ever takes another
    Turing machine as an input no Turing machine can >>>>>>>>>>>>>>> directly compute the mapping from an input that
    is not in its domain.

    Therefore Turing machines can't do arithmetic because no >>>>>>>>>>>>>> Turing machine can take an actual number as input. >>>>>>>>>>>>>>
    Agreed?
    Finite string representations of numbers always behave >>>>>>>>>>>>> exactly the same way as if they were numbers.

    Finite string representations of Turing Machines do
    not always behave exactly the same way as the machine >>>>>>>>>>>>> in one single exceptional case that no one ever noticed >>>>>>>>>>>>> before:

    Which is just another way of saying the halting function is >>>>>>>>>>>> not a computable function, as Linz and others have proved >>>>>>>>>>>> and as you have *explicitly* agreed is correct.

    *No it is not another way of saying that*

    It is a way of saying that the halting function
    is not computable because

    Assuming it is causes contradictions.

    The halting problem causes no contradiction when
    it is understood that M.H ⟨M⟩ ⟨M⟩ correctly reports
    on the actual behavior of its actual input.

    In other words, H isn't giving the answer required by the
    specification and therefore doesn't meet the definition of a
    total halt decider / termination analyzer.


    When the spec requires reporting on a non-input
    and ignores reporting on an input then we know
    that spec is wrong.

    In other words Turning machines can't add 2 + 2 because the number >>>>>> 2 is a non-input, so any specification for a Turing machine to
    perform addition must be wrong.

    Agreed?

    M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qy
    M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn

    No. the behavior specified by the input to M.H ⟨M⟩ ⟨M⟩

    i.e. finite string ⟨M⟩ which is defined to be a description of
    algorithm M, proven to be valid by UTM ⟨M⟩ ⟨M⟩ having the exact same
    behavior as M ⟨M⟩

    is provably different behavior than the behavior of
    M applied to ⟨M⟩.


    False, as shown above.

    So you do not understand that M.H ⟨M⟩ ⟨M⟩
    repeats recursively simulating itself?


    Only finitely, as the simulation UTM ⟨M⟩ ⟨M⟩ is exactly the same as >> the simulation M.H ⟨M⟩ ⟨M⟩ up to the point that M.H aborts, proving >> that algorithm M halts.

    I have proven that to be factually incorrect
    numerous times on the basis of HHH(DDD) and HHH1(DDD).

    No, you haven't.


    HHH simulates DD then simulates an instance of itself
    that cannot possibly return.

    But "itself" isn't a factor in the simulation.

    They both simulate the call HHH and then (should) simulate the code of HHH.

    Since HHH is the same program in both cases, as correct simulation isn't
    a function of who does it, they both get the same answer.

    Your problem is you try to lie and say that call HHH does something
    different if HHH simulates it, without any basis, which is just a stupid
    lie.

    You just don't understand what "correct simulation" is, or what the x86 language is, because you are too stupid and ignorant.


    HHH1 simulates DD then simulates an instance of HHH
    that does return.

    Is your name Dave?


    Have you stopped watching illegal kiddie porn?

    It was established that there was probable cause and evidence that you have.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Tue Aug 12 21:56:11 2025
    On 8/12/25 11:33 AM, olcott wrote:
    On 8/12/2025 7:11 AM, dbush wrote:
    On 8/12/2025 12:00 AM, olcott wrote:
    On 8/11/2025 10:51 PM, dbush wrote:

    Only finitely, as the simulation UTM ⟨M⟩ ⟨M⟩ is exactly the same as
    the simulation M.H ⟨M⟩ ⟨M⟩ up to the point that M.H aborts, proving
    that algorithm M halts.

    I have proven that to be factually incorrect
    numerous times on the basis of HHH(DDD) and HHH1(DDD).

    HHH simulates DD then simulates an instance of itself
    that cannot possibly return.

    i.e. HHH simulates DD then simulates an instance of HHH that it aborts


    HHH1 simulates DD then simulates an instance of HHH
    that does return.

    i.e. HHH1 simulates DD then simulates an instance of HHH but does not
    abort it allowing it to reach a final state.


    Both are the exactly the same up to the point that HHH aborts.

    The behavior varies not because HHH aborts.
    Their behavior varies because DDD calls HHH(DDD) in
    recursive emulation and DDD does not call HHH1(DDD) at all.

    Which doesn't actually affect what the code does.

    If HHH simulating DD which calls HHH to simulate DD causes an infinte
    loop, then HHH1 simulatihg DD which calls HHH to simulate DD which calls
    HHH to simulate DD also would create the same infinite loop, as the
    simulate HHH would get stuck too, but it doesn't, because it does abort,
    and thus the pattern isn't a non-halting pattern in DD by the actual definition.

    It may be a non-halting pattern in HHH by POOPS, but that isn't the
    question here.


    Both are exactly the same until their DDD calls HHH(DDD).
    There are many other steps after that before HHH(DDD) aborts.


    And what actually behaves differently?

    All you try to do is non-simulation unsound logic to try to say that it
    must be non-halting, even when you are shown the fact that it halts.

    All you are doing is proving that you think it is ok to reject the
    actual definition of terms and replace them with errors which cause your
    system to be contradictory, and then try to blame it all on the original
    system which you left.

    Sorry, you are just proving that are just a pathological liar.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Tue Aug 12 21:58:44 2025
    On 8/12/25 1:11 PM, olcott wrote:
    On 8/12/2025 7:12 AM, dbush wrote:
    On 8/12/2025 1:01 AM, olcott wrote:
    On 8/11/2025 10:51 PM, dbush wrote:
    On 8/11/2025 11:49 PM, olcott wrote:
    On 8/11/2025 10:42 PM, dbush wrote:
    On 8/11/2025 11:39 PM, olcott wrote:

    M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qy
    M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn

    No. the behavior specified by the input to M.H ⟨M⟩ ⟨M⟩

    i.e. finite string ⟨M⟩ which is defined to be a description of >>>>>> algorithm M, proven to be valid by UTM ⟨M⟩ ⟨M⟩ having the exact >>>>>> same behavior as M ⟨M⟩

    is provably different behavior than the behavior of
    M applied to ⟨M⟩.


    False, as shown above.

    So you do not understand that M.H ⟨M⟩ ⟨M⟩
    repeats recursively simulating itself?


    Only finitely, as the simulation UTM ⟨M⟩ ⟨M⟩ is exactly the same as
    the simulation M.H ⟨M⟩ ⟨M⟩ up to the point that M.H aborts, proving
    that algorithm M halts.

    M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qy
    M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn
    UTM ⟨M⟩ ⟨M⟩ has the same behavior as M ⟨M⟩
    and different behavior than M.H ⟨M⟩ ⟨M⟩.

    Only because M.H aborts, and up to the point it does both are exactly
    the same.

    In other words you believe that ⟨M⟩ ⟨M⟩ correctly
    simulated by M.H would eventually reach its own
    simulated final halt state with no need for any abort.


    No, since H doesn't do a correct simulation on the input (M) (M)
    But the correct simulation of (M)(M) does reach a final state, as the simulation sees that the M.H that M uses aborts its simulation and
    returns to M.qn where M halts.

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