1. Forum
  2. Usenet
  3. COMP.THEORY

  • Re: Halt Deciders must be computable functions --- dbush was always wro

    From joes@21:1/5 to All on Mon Mar 24 00:01:53 2025
    Am Sun, 23 Mar 2025 15:08:25 -0500 schrieb olcott:

    The behavior of a directly executing Turing Machine cannot be computed because a directly executing Turing machine cannot be the input to any computable function.
    Lol. This is such a ridiculously silly objection. Of course a TM is
    nothing but a finite string (or can be encoded as such). TMs are
    most definitely computable - UTMs are possible.

    --
    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 Mon Mar 24 10:00:38 2025
    On 2025-03-23 20:08:25 +0000, olcott said:

    On 3/23/2025 4:49 AM, Mikko wrote:
    On 2025-03-22 15:47:03 +0000, olcott said:

    On 3/22/2025 9:57 AM, Mikko wrote:
    On 2025-03-21 15:25:09 +0000, olcott said:

    On 3/21/2025 10:00 AM, olcott wrote:
    On 3/21/2025 9:44 AM, dbush wrote:
    On 3/17/2025 11:29 PM, olcott wrote:
    On 3/17/2025 8:25 PM, dbush wrote:
    On 3/17/2025 9:18 PM, olcott wrote:
    On 3/17/2025 7:48 PM, dbush wrote:
    On 3/17/2025 8:44 PM, olcott wrote:
    On 3/17/2025 7:22 PM, dbush wrote:
    On 3/17/2025 8:18 PM, olcott wrote:
    On 3/17/2025 7:00 PM, dbush wrote:
    On 3/17/2025 7:51 PM, olcott wrote:
    On 3/17/2025 5:15 PM, dbush wrote:
    On 3/17/2025 6:10 PM, olcott wrote:

    The halt decider does not and cannot possibly >>>>>>>>>>>>>>>>>> compute the mapping from the actual behavior >>>>>>>>>>>>>>>>>> of an executing process.


    No one claimed it should.  What it must do is determine what would
    happen in the hypothetical case that a direct execution is done.


    It can only do that when it assumes that the behavior >>>>>>>>>>>>>>>> specified by the semantics of its input machine language >>>>>>>>>>>>>>>> exactly matches this behavior. Its only basis is this >>>>>>>>>>>>>>>> input finite string.

    i.e. the semantics of the x86 language when those actual instructions
    are actually executed on an actual x86 processor. >>>>>>>>>>>>>>>

    A termination analyzer has no access to that.

    The input is required to be a complete description of the program that
    can be used to determine its full behavior.  In the case of DD, that
    description is the code of the function DD, the code of the function
    HHH, and everything that HHH calls down to the OS level. >>>>>>>>>>>>
    It does do that and this behavior does specify

    Halting behavior when executed directly, which is what is to be >>>>>>>>>>> reported on as per the requirements:



    It has always been incorrectly assumed that the input
    finite string is a perfect proxy for the behavior
    of the direct execution.

    False.  The input finite string is REQUIRED to be a perfect proxy for
    direct execution, as per the requirements:


    It looks like you simply don't understand that a
    counter-factual requirement is necessarily incorrect.

    Category error.  Requirements can't be false.  They can however be >>>>>>> impossible to satisfy.


    When the definition of a [HALT decider] contradicts the definition of a >>>>>> [decider] in the same field of inquiry at least one of them is
    incorrect.

    No, there is nothing incorrect there. It simply means a halpt decider
    is not a decider,

    It has always been stipulated that a [halt decider] is a type
    of [decider]. This means that every halt decider only has the
    behavior that its finite string input specifies as its only basis.

    No, it has not. "Halting decider" can be defined without mentioning
    "decider" and some authors do so.

    I forgot that the notion of computable function already proves my point

    Maybe, if you have a point. But it does not prove your false claim above.

    --
    Mikko

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Mon Mar 24 07:23:44 2025
    On 3/23/25 8:59 PM, olcott wrote:
    On 3/23/2025 7:01 PM, joes wrote:
    Am Sun, 23 Mar 2025 15:08:25 -0500 schrieb olcott:

    The behavior of a directly executing Turing Machine cannot be computed
    because a directly executing Turing machine cannot be the input to any
    computable function.
    Lol. This is such a ridiculously silly objection. Of course a TM is
    nothing but a finite string (or can be encoded as such). TMs are
    most definitely computable - UTMs are possible.


    It is enormously more nuanced than that. https://www.liarparadox.org/Linz_Proof.pdf

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    Incorrect, UTM was never there;, so you are just showing that your logic
    was a lie.


    When we define the Peter Linz Ĥ with a UTM
    that simulates a finite number of "moves"
    before transitioning to Ĥ.qn then Ĥ reaches
    Ĥ.qn and the simulated ⟨Ĥ⟩ cannot possibly
    reach ⟨Ĥ.qn⟩.


    Which is impossible, as such a thing is not a UTM.

    You are just showing that your logic is based on the presumption of the impossible and lies to fill the holes.

    Sorry, you are just burying your reputation in the lake of fire.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From joes@21:1/5 to All on Mon Mar 24 15:34:24 2025
    Am Mon, 24 Mar 2025 09:49:34 -0500 schrieb olcott:
    On 3/24/2025 6:23 AM, Richard Damon wrote:
    On 3/23/25 8:59 PM, olcott wrote:
    On 3/23/2025 7:01 PM, joes wrote:
    Am Sun, 23 Mar 2025 15:08:25 -0500 schrieb olcott:

    The behavior of a directly executing Turing Machine cannot be
    computed because a directly executing Turing machine cannot be the
    input to any computable function.
    Lol. This is such a ridiculously silly objection. Of course a TM is
    nothing but a finite string (or can be encoded as such). TMs are most
    definitely computable - UTMs are possible.

    It is enormously more nuanced than that.
    https://www.liarparadox.org/Linz_Proof.pdf

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    Incorrect, UTM was never there;, so you are just showing that your
    logic was a lie.


    When we define the Peter Linz Ĥ with a UTM that simulates a finite
    number of "moves"
    before transitioning to Ĥ.qn then Ĥ reaches Ĥ.qn and the simulated ⟨Ĥ⟩
    cannot possibly reach ⟨Ĥ.qn⟩.

    Which is impossible, as such a thing is not a UTM.

    Saying that a UTM that simulates a finite number of states is not a UTM
    is like saying that a red car is not a car.
    The other way around: a limited TM is not universal.

    You are just showing that your logic is based on the presumption of the
    impossible and lies to fill the holes.
    It is not impossible for a UTM to simulate a finite number of states.
    Neither is it identical to the direct execution (which doesn't stop).

    --
    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 Mon Mar 24 21:28:17 2025
    On 3/24/25 10:49 AM, olcott wrote:
    On 3/24/2025 6:23 AM, Richard Damon wrote:
    On 3/23/25 8:59 PM, olcott wrote:
    On 3/23/2025 7:01 PM, joes wrote:
    Am Sun, 23 Mar 2025 15:08:25 -0500 schrieb olcott:

    The behavior of a directly executing Turing Machine cannot be computed >>>>> because a directly executing Turing machine cannot be the input to any >>>>> computable function.
    Lol. This is such a ridiculously silly objection. Of course a TM is
    nothing but a finite string (or can be encoded as such). TMs are
    most definitely computable - UTMs are possible.


    It is enormously more nuanced than that.
    https://www.liarparadox.org/Linz_Proof.pdf

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    Incorrect, UTM was never there;, so you are just showing that your
    logic was a lie.


    When we define the Peter Linz Ĥ with a UTM
    that simulates a finite number of "moves"
    before transitioning to Ĥ.qn then Ĥ reaches
    Ĥ.qn and the simulated ⟨Ĥ⟩ cannot possibly
    reach ⟨Ĥ.qn⟩.


    Which is impossible, as such a thing is not a UTM.


    Saying that a UTM that simulates a finite number of states
    is not a UTM is like saying that a red car is not a car.

    Nope. Just shows you don't understand the meaning of the term.

    Is a dead-man switch a dead-man?

    Is a street legal car that you have modified by taking out the
    headlights still street legal?

    No, definintion matter, and changing something might make it no longer
    qualify as what it originally was.


    You are just showing that your logic is based on the presumption of
    the impossible and lies to fill the holes.

    It is not impossible for a UTM to simulate a finite number of states.

    No, but it only does that if it reaches the final state.



    Sorry, you are just burying your reputation in the lake of fire.

    Credibility has always been horse shit a fake measure of correctness.
    If it wasn't for credibility https://en.wikipedia.org/wiki/ Two_Dogmas_of_Empiricism would have been rejected as nonsense long ago.
    Goofy Quine thought there was a cycle in a tree structure.

    The term Bachelor(X) is assigned the meaning of
    (~Married(X) & Male(X) & Adult(X))


    In other words, you admit you don't understand the meaning of the words
    you are using and throwing up a smoke screen.

    Look up the DEFINITION of a UTM and tell me how a machine that only
    simulates part of its input meets that definition.

    I'll give you a start, a simple definition of a UTM is a machine that
    can replicate the full behavior of any other Turing Machine, given a
    suitable description of that machine.

    Note, Turing Machine Theory never talks about machines ever stopping on
    their own except at a final state, and thus a UTM, to be a UTM, also
    never stops before it reaches that final state, or it didn't fulfill the definition.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mikko@21:1/5 to olcott on Tue Mar 25 11:33:01 2025
    On 2025-03-24 14:21:01 +0000, olcott said:

    On 3/24/2025 3:00 AM, Mikko wrote:
    On 2025-03-23 20:08:25 +0000, olcott said:

    On 3/23/2025 4:49 AM, Mikko wrote:
    On 2025-03-22 15:47:03 +0000, olcott said:

    On 3/22/2025 9:57 AM, Mikko wrote:
    On 2025-03-21 15:25:09 +0000, olcott said:

    On 3/21/2025 10:00 AM, olcott wrote:
    On 3/21/2025 9:44 AM, dbush wrote:
    On 3/17/2025 11:29 PM, olcott wrote:
    On 3/17/2025 8:25 PM, dbush wrote:
    On 3/17/2025 9:18 PM, olcott wrote:
    On 3/17/2025 7:48 PM, dbush wrote:
    On 3/17/2025 8:44 PM, olcott wrote:
    On 3/17/2025 7:22 PM, dbush wrote:
    On 3/17/2025 8:18 PM, olcott wrote:
    On 3/17/2025 7:00 PM, dbush wrote:
    On 3/17/2025 7:51 PM, olcott wrote:
    On 3/17/2025 5:15 PM, dbush wrote:
    On 3/17/2025 6:10 PM, olcott wrote:

    The halt decider does not and cannot possibly >>>>>>>>>>>>>>>>>>>> compute the mapping from the actual behavior >>>>>>>>>>>>>>>>>>>> of an executing process.


    No one claimed it should.  What it must do is determine what would
    happen in the hypothetical case that a direct execution is done.


    It can only do that when it assumes that the behavior >>>>>>>>>>>>>>>>>> specified by the semantics of its input machine language >>>>>>>>>>>>>>>>>> exactly matches this behavior. Its only basis is this >>>>>>>>>>>>>>>>>> input finite string.

    i.e. the semantics of the x86 language when those actual instructions
    are actually executed on an actual x86 processor. >>>>>>>>>>>>>>>>>

    A termination analyzer has no access to that.

    The input is required to be a complete description of the program that
    can be used to determine its full behavior. In the case of DD, that
    description is the code of the function DD, the code of the function
    HHH, and everything that HHH calls down to the OS level. >>>>>>>>>>>>>>
    It does do that and this behavior does specify

    Halting behavior when executed directly, which is what is to be >>>>>>>>>>>>> reported on as per the requirements:



    It has always been incorrectly assumed that the input
    finite string is a perfect proxy for the behavior
    of the direct execution.

    False.  The input finite string is REQUIRED to be a perfect proxy for
    direct execution, as per the requirements:


    It looks like you simply don't understand that a
    counter-factual requirement is necessarily incorrect.

    Category error.  Requirements can't be false.  They can however be >>>>>>>>> impossible to satisfy.


    When the definition of a [HALT decider] contradicts the definition of a
    [decider] in the same field of inquiry at least one of them is >>>>>>>> incorrect.

    No, there is nothing incorrect there. It simply means a halpt decider >>>>>> is not a decider,

    It has always been stipulated that a [halt decider] is a type
    of [decider]. This means that every halt decider only has the
    behavior that its finite string input specifies as its only basis.

    No, it has not. "Halting decider" can be defined without mentioning
    "decider" and some authors do so.

    I forgot that the notion of computable function already proves my point

    Maybe, if you have a point. But it does not prove your false claim above.

    No Turing Machine computation can report on the behavior
    of any directly executing Turing Machine because no directly
    executing Turing machine is a finite string input.

    given an input of the function domain it
    can return the corresponding output. https://en.wikipedia.org/wiki/Computable_function

    Ia that your "point"? At least that was not what you were talking about
    when you falsely claimed that "It has always been stipulated that a
    [halt decider] is a type of [decider]" and is therefore irrelevant to
    that
    message and the discussion after that.

    --
    Mikko

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Tue Mar 25 21:42:39 2025
    On 3/25/25 8:40 AM, olcott wrote:
    On 3/25/2025 4:33 AM, Mikko wrote:
    On 2025-03-24 14:21:01 +0000, olcott said:

    On 3/24/2025 3:00 AM, Mikko wrote:
    On 2025-03-23 20:08:25 +0000, olcott said:

    On 3/23/2025 4:49 AM, Mikko wrote:
    On 2025-03-22 15:47:03 +0000, olcott said:

    On 3/22/2025 9:57 AM, Mikko wrote:
    On 2025-03-21 15:25:09 +0000, olcott said:

    On 3/21/2025 10:00 AM, olcott wrote:
    On 3/21/2025 9:44 AM, dbush wrote:
    On 3/17/2025 11:29 PM, olcott wrote:
    On 3/17/2025 8:25 PM, dbush wrote:
    On 3/17/2025 9:18 PM, olcott wrote:
    On 3/17/2025 7:48 PM, dbush wrote:
    On 3/17/2025 8:44 PM, olcott wrote:
    On 3/17/2025 7:22 PM, dbush wrote:
    On 3/17/2025 8:18 PM, olcott wrote:
    On 3/17/2025 7:00 PM, dbush wrote:
    On 3/17/2025 7:51 PM, olcott wrote:
    On 3/17/2025 5:15 PM, dbush wrote:
    On 3/17/2025 6:10 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>
    The halt decider does not and cannot possibly >>>>>>>>>>>>>>>>>>>>>> compute the mapping from the actual behavior >>>>>>>>>>>>>>>>>>>>>> of an executing process.


    No one claimed it should.  What it must do is >>>>>>>>>>>>>>>>>>>>> determine what would happen in the hypothetical >>>>>>>>>>>>>>>>>>>>> case that a direct execution is done. >>>>>>>>>>>>>>>>>>>>>

    It can only do that when it assumes that the behavior >>>>>>>>>>>>>>>>>>>> specified by the semantics of its input machine >>>>>>>>>>>>>>>>>>>> language
    exactly matches this behavior. Its only basis is this >>>>>>>>>>>>>>>>>>>> input finite string.

    i.e. the semantics of the x86 language when those >>>>>>>>>>>>>>>>>>> actual instructions are actually executed on an >>>>>>>>>>>>>>>>>>> actual x86 processor.


    A termination analyzer has no access to that. >>>>>>>>>>>>>>>>>
    The input is required to be a complete description of >>>>>>>>>>>>>>>>> the program that can be used to determine its full >>>>>>>>>>>>>>>>> behavior.  In the case of DD, that description is the >>>>>>>>>>>>>>>>> code of the function DD, the code of the function HHH, >>>>>>>>>>>>>>>>> and everything that HHH calls down to the OS level. >>>>>>>>>>>>>>>>
    It does do that and this behavior does specify

    Halting behavior when executed directly, which is what is >>>>>>>>>>>>>>> to be reported on as per the requirements:



    It has always been incorrectly assumed that the input >>>>>>>>>>>>>> finite string is a perfect proxy for the behavior
    of the direct execution.

    False.  The input finite string is REQUIRED to be a perfect >>>>>>>>>>>>> proxy for direct execution, as per the requirements: >>>>>>>>>>>>>

    It looks like you simply don't understand that a
    counter-factual requirement is necessarily incorrect.

    Category error.  Requirements can't be false.  They can >>>>>>>>>>> however be impossible to satisfy.


    When the definition of a [HALT decider] contradicts the
    definition of a [decider] in the same field of inquiry at
    least one of them is incorrect.

    No, there is nothing incorrect there. It simply means a halpt
    decider
    is not a decider,

    It has always been stipulated that a [halt decider] is a type
    of [decider]. This means that every halt decider only has the
    behavior that its finite string input specifies as its only basis. >>>>>>
    No, it has not. "Halting decider" can be defined without mentioning >>>>>> "decider" and some authors do so.

    I forgot that the notion of computable function already proves my
    point

    Maybe, if you have a point. But it does not prove your false claim
    above.

    No Turing Machine computation can report on the behavior
    of any directly executing Turing Machine because no directly
    executing Turing machine is a finite string input.

      given an input of the function domain it
      can return the corresponding output.
    https://en.wikipedia.org/wiki/Computable_function

    Ia that your "point"? At least that was not what you were talking about
    when you falsely claimed that "It has always been stipulated that a
    [halt decider] is a type of [decider]" and is therefore irrelevant to
    that
    message and the discussion after that.


    A halt decider <is> and has always been a type of decider.
    The nothing of computable function  proves my point another way.

    All Turing computable functions compute the mapping from an
    input finite string on the basis of something that this finite
    string specifies. No TM every has any psychic ability.



    Right, but to be the <Foo> decider (like a Halt Decider) the mapping
    they compute has to match the <Foo?> mapping.

    The Halt Mapping is DEFINED as the mapping of a program (or its
    representation) to whether that machine will halt or not.

    Part of the question is whether this forms a computable function, there
    is no presumption that it is, that is the actual prime question.

    Turing Machine can only compute the computable mappings, so if no Turing Machine exists that can compute it, that just means the mapping isn't computable.

    This is EXACTLY what Turing proved with his proof, that ANY Turing
    Machine will have at least one input given to it that will will map to a different result than the Halting mapping.

    There is nothing wrong with that result, it just means that Halting is
    one of the Aleph_1 possible mappings that isn't computable with the
    Aleph_0 possible deciders.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mikko@21:1/5 to olcott on Wed Mar 26 09:38:55 2025
    On 2025-03-25 12:40:08 +0000, olcott said:

    On 3/25/2025 4:33 AM, Mikko wrote:
    On 2025-03-24 14:21:01 +0000, olcott said:

    On 3/24/2025 3:00 AM, Mikko wrote:
    On 2025-03-23 20:08:25 +0000, olcott said:

    On 3/23/2025 4:49 AM, Mikko wrote:
    On 2025-03-22 15:47:03 +0000, olcott said:

    On 3/22/2025 9:57 AM, Mikko wrote:
    On 2025-03-21 15:25:09 +0000, olcott said:

    On 3/21/2025 10:00 AM, olcott wrote:
    On 3/21/2025 9:44 AM, dbush wrote:
    On 3/17/2025 11:29 PM, olcott wrote:
    On 3/17/2025 8:25 PM, dbush wrote:
    On 3/17/2025 9:18 PM, olcott wrote:
    On 3/17/2025 7:48 PM, dbush wrote:
    On 3/17/2025 8:44 PM, olcott wrote:
    On 3/17/2025 7:22 PM, dbush wrote:
    On 3/17/2025 8:18 PM, olcott wrote:
    On 3/17/2025 7:00 PM, dbush wrote:
    On 3/17/2025 7:51 PM, olcott wrote:
    On 3/17/2025 5:15 PM, dbush wrote:
    On 3/17/2025 6:10 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>
    The halt decider does not and cannot possibly >>>>>>>>>>>>>>>>>>>>>> compute the mapping from the actual behavior >>>>>>>>>>>>>>>>>>>>>> of an executing process.


    No one claimed it should.  What it must do is determine what would
    happen in the hypothetical case that a direct execution is done.


    It can only do that when it assumes that the behavior >>>>>>>>>>>>>>>>>>>> specified by the semantics of its input machine language >>>>>>>>>>>>>>>>>>>> exactly matches this behavior. Its only basis is this >>>>>>>>>>>>>>>>>>>> input finite string.

    i.e. the semantics of the x86 language when those actual instructions
    are actually executed on an actual x86 processor. >>>>>>>>>>>>>>>>>>>

    A termination analyzer has no access to that. >>>>>>>>>>>>>>>>>
    The input is required to be a complete description of the program that
    can be used to determine its full behavior.  In the case of DD, that
    description is the code of the function DD, the code of the function
    HHH, and everything that HHH calls down to the OS level. >>>>>>>>>>>>>>>>
    It does do that and this behavior does specify

    Halting behavior when executed directly, which is what is to be >>>>>>>>>>>>>>> reported on as per the requirements:



    It has always been incorrectly assumed that the input >>>>>>>>>>>>>> finite string is a perfect proxy for the behavior
    of the direct execution.

    False.  The input finite string is REQUIRED to be a perfect proxy for
    direct execution, as per the requirements:


    It looks like you simply don't understand that a
    counter-factual requirement is necessarily incorrect.

    Category error.  Requirements can't be false.  They can however be
    impossible to satisfy.


    When the definition of a [HALT decider] contradicts the definition of a
    [decider] in the same field of inquiry at least one of them is >>>>>>>>>> incorrect.

    No, there is nothing incorrect there. It simply means a halpt decider >>>>>>>> is not a decider,

    It has always been stipulated that a [halt decider] is a type
    of [decider]. This means that every halt decider only has the
    behavior that its finite string input specifies as its only basis. >>>>>>
    No, it has not. "Halting decider" can be defined without mentioning >>>>>> "decider" and some authors do so.

    I forgot that the notion of computable function already proves my point >>>>
    Maybe, if you have a point. But it does not prove your false claim above. >>>
    No Turing Machine computation can report on the behavior
    of any directly executing Turing Machine because no directly
    executing Turing machine is a finite string input.

      given an input of the function domain it
      can return the corresponding output.
    https://en.wikipedia.org/wiki/Computable_function

    Ia that your "point"? At least that was not what you were talking about
    when you falsely claimed that "It has always been stipulated that a
    [halt decider] is a type of [decider]" and is therefore irrelevant to
    that
    message and the discussion after that.

    A halt decider <is> and has always been a type of decider.

    That is not stipulated. Most authors that define both terms define them
    so that the definitions imply that a halt decider is a decider. But an implication is not a stipulation.

    --
    Mikko

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