• Re: Decidability Decider H

    From Python@21:1/5 to Peter Olcott on Mon Jul 3 03:11:38 2023
    XPost: comp.theory, sci.logic

    Child molester, Peter Olcott wrote:
    A single H can consistently correctly determine whether or not its input
    is pathological relative to itself. When H(D,D) is invoked in
    decidability decider mode determines that D is pathological relative to itself this enables a batch file to invoke H1(D,D) to get the actual
    behavior of the directly executed D(D). H1 is identical to H except for
    the pathological relationship to H.


    No. It can't.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to All on Sun Jul 2 19:45:58 2023
    XPost: comp.theory, sci.logic

    A single H can consistently correctly determine whether or not its input
    is pathological relative to itself. When H(D,D) is invoked in
    decidability decider mode determines that D is pathological relative to
    itself this enables a batch file to invoke H1(D,D) to get the actual
    behavior of the directly executed D(D). H1 is identical to H except for
    the pathological relationship to H.

    --
    Copyright 2023 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 Sun Jul 2 21:40:07 2023
    XPost: comp.theory, sci.logic

    On 7/2/23 8:45 PM, olcott wrote:
    A single H can consistently correctly determine whether or not its input
    is pathological relative to itself. When H(D,D) is invoked in
    decidability decider mode determines that D is pathological relative to itself this enables a batch file to invoke H1(D,D) to get the actual
    behavior of the directly executed D(D). H1 is identical to H except for
    the pathological relationship to H.



    And does an input D that uses this FULL algorithm give your algorithm
    problems?

    Since H(D,D) will (apparently) determine that the input is pathological,
    and thus defer to H1(D,D), then when we actually run D, appearently it
    will get that same answer from H1 and do the opposite of it, and thus H1
    will be wrong.

    Remember, the "Pathological" program is built on a copy of the ACTUAL
    program that you ask to decide on it, including ALL of its "tricks",
    including things like this "batch processing".

    You seem to be assuming that there is some "Operationg System" outside
    the Decider - Input structure, but there isn't, at least not one that
    can affect the answer of the problem.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Sun Jul 2 21:27:33 2023
    XPost: comp.theory, sci.logic

    On 7/2/23 8:45 PM, olcott wrote:
    A single H can consistently correctly determine whether or not its input
    is pathological relative to itself. When H(D,D) is invoked in
    decidability decider mode determines that D is pathological relative to itself this enables a batch file to invoke H1(D,D) to get the actual
    behavior of the directly executed D(D). H1 is identical to H except for
    the pathological relationship to H.


    Only if its input isn't a Turing Complete environment. TO be Turing
    Complete, teh environment needs to allow the machine being decided on
    have its own (private) copy of the Halt Decider, at which point your
    algorith for H can't tell when the input has called that copy.

    Note, the representation of the copy that it is using doesn't need to
    match that of the decider deciding on it to be an equivalent copy, so H
    can't just use a simple sub-string compare to detect it.

    You have just shown yourself too ignorant of what you are actually
    talking about to understand this, so I am expecting some stupid response.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Richard Damon on Sun Jul 2 21:01:07 2023
    XPost: comp.theory, sci.logic

    On 7/2/2023 8:40 PM, Richard Damon wrote:
    On 7/2/23 8:45 PM, olcott wrote:
    A single H can consistently correctly determine whether or not its input
    is pathological relative to itself. When H(D,D) is invoked in
    decidability decider mode determines that D is pathological relative to
    itself this enables a batch file to invoke H1(D,D) to get the actual
    behavior of the directly executed D(D). H1 is identical to H except for
    the pathological relationship to H.



    And does an input D that uses this FULL algorithm give your algorithm problems?

    Since H(D,D) will (apparently) determine that the input is pathological,
    and thus defer to H1(D,D), then when we actually run D, appearently it
    will get that same answer from H1 and do the opposite of it, and thus H1
    will be wrong.

    Remember, the "Pathological" program is built on a copy of the ACTUAL
    program that you ask to decide on it, including ALL of its "tricks", including things like this "batch processing".

    You seem to be assuming that there is some "Operationg System" outside
    the Decider - Input structure, but there isn't, at least not one that
    can affect the answer of the problem.

    I spent 12 hours a day for the last 10 days getting the copy the input
    working. When H(D,D) (in decidability decider mode) detects that its
    input is in the well defined set of pathological inputs it returns 0
    indicating that its input is undecidable. The batch file that invoked H
    then knows to invoke H1(D,D) to correctly report that D(D) halts.

    This solution does seem to work correctly on every conventional proof in
    every textbook.

    --
    Copyright 2023 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 Python@21:1/5 to Fraudster Peter Olcott on Mon Jul 3 04:05:04 2023
    XPost: comp.theory, sci.logic

    Fraudster Peter Olcott wrote:
    ...
    This solution does seem to work correctly on every conventional proof in every textbook.

    not. at. all.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Sun Jul 2 22:37:37 2023
    XPost: comp.theory, sci.logic

    On 7/2/23 10:01 PM, olcott wrote:
    On 7/2/2023 8:40 PM, Richard Damon wrote:
    On 7/2/23 8:45 PM, olcott wrote:
    A single H can consistently correctly determine whether or not its input >>> is pathological relative to itself. When H(D,D) is invoked in
    decidability decider mode determines that D is pathological relative to
    itself this enables a batch file to invoke H1(D,D) to get the actual
    behavior of the directly executed D(D). H1 is identical to H except for
    the pathological relationship to H.



    And does an input D that uses this FULL algorithm give your algorithm
    problems?

    Since H(D,D) will (apparently) determine that the input is
    pathological, and thus defer to H1(D,D), then when we actually run D,
    appearently it will get that same answer from H1 and do the opposite
    of it, and thus H1 will be wrong.

    Remember, the "Pathological" program is built on a copy of the ACTUAL
    program that you ask to decide on it, including ALL of its "tricks",
    including things like this "batch processing".

    You seem to be assuming that there is some "Operationg System" outside
    the Decider - Input structure, but there isn't, at least not one that
    can affect the answer of the problem.

    I spent 12 hours a day for the last 10 days getting the copy the input working. When H(D,D) (in decidability decider mode) detects that its
    input is in the well defined set of pathological inputs it returns 0 indicating that its input is undecidable. The batch file that invoked H
    then knows to invoke H1(D,D) to correctly report that D(D) halts.

    This solution does seem to work correctly on every conventional proof in every textbook.


    So, what is the definition of that "Well Definde Set"? or is this just
    another of your moronic oxymorons.

    Note, H can't have "Modes" that are externally controlled, as it has no
    input to control that, it is just a decider that is given an input to
    decide on.

    If you have some "fuller" algorithm you use to decide that uses the sub-function H to do a step, then D needs to be built on that fuller
    algorithm, as THAT is what you are actually claiming to be your halt
    decider.

    I guess you are just making it painfully obvious that you don't
    understand the nature of the problem you claim to be working on.

    So, since it seems that you have some sort of "batch file" that is your
    actual decider, you need to show how you have a program invoke that and
    do tha tin D. If you can't, you are just admitting that you are not
    working on the actual problem defined, but are playing games in the
    sub-Turing Complete versions of the problem, which has many known solutions.

    It seems that you just wasted 120 hours of work and just proved that you
    are totally ignorant of the problem and don't know what you are talking
    aobut.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Richard Damon on Sun Jul 2 21:48:13 2023
    XPost: comp.theory, sci.logic

    On 7/2/2023 9:41 PM, Richard Damon wrote:
    On 7/2/23 10:01 PM, olcott wrote:
    On 7/2/2023 8:40 PM, Richard Damon wrote:
    On 7/2/23 8:45 PM, olcott wrote:
    A single H can consistently correctly determine whether or not its
    input
    is pathological relative to itself. When H(D,D) is invoked in
    decidability decider mode determines that D is pathological relative to >>>> itself this enables a batch file to invoke H1(D,D) to get the actual
    behavior of the directly executed D(D). H1 is identical to H except for >>>> the pathological relationship to H.



    And does an input D that uses this FULL algorithm give your algorithm
    problems?

    Since H(D,D) will (apparently) determine that the input is
    pathological, and thus defer to H1(D,D), then when we actually run D,
    appearently it will get that same answer from H1 and do the opposite
    of it, and thus H1 will be wrong.

    Remember, the "Pathological" program is built on a copy of the ACTUAL
    program that you ask to decide on it, including ALL of its "tricks",
    including things like this "batch processing".

    You seem to be assuming that there is some "Operationg System"
    outside the Decider - Input structure, but there isn't, at least not
    one that can affect the answer of the problem.

    I spent 12 hours a day for the last 10 days getting the copy the input
    working. When H(D,D) (in decidability decider mode) detects that its
    input is in the well defined set of pathological inputs it returns 0
    indicating that its input is undecidable. The batch file that invoked H
    then knows to invoke H1(D,D) to correctly report that D(D) halts.

    This solution does seem to work correctly on every conventional proof in
    every textbook.


    So, did you make your "conventional proof" template actually use a copy
    of your ACTUAL decider (which seems to be your "batch file" not the C funciton H), or are you just admitting that you wasted 120 hours looking
    at the wrong thing because you have made yourself intentionally ignorant
    of the subject so you don't understand what you are trying to do.

    New_D copies its input and simulates its input with its input.
    It never sees New_H.

    --
    Copyright 2023 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 olcott@21:1/5 to Richard Damon on Sun Jul 2 22:10:18 2023
    XPost: comp.theory, sci.logic

    On 7/2/2023 9:37 PM, Richard Damon wrote:
    On 7/2/23 10:01 PM, olcott wrote:
    On 7/2/2023 8:40 PM, Richard Damon wrote:
    On 7/2/23 8:45 PM, olcott wrote:
    A single H can consistently correctly determine whether or not its
    input
    is pathological relative to itself. When H(D,D) is invoked in
    decidability decider mode determines that D is pathological relative to >>>> itself this enables a batch file to invoke H1(D,D) to get the actual
    behavior of the directly executed D(D). H1 is identical to H except for >>>> the pathological relationship to H.



    And does an input D that uses this FULL algorithm give your algorithm
    problems?

    Since H(D,D) will (apparently) determine that the input is
    pathological, and thus defer to H1(D,D), then when we actually run D,
    appearently it will get that same answer from H1 and do the opposite
    of it, and thus H1 will be wrong.

    Remember, the "Pathological" program is built on a copy of the ACTUAL
    program that you ask to decide on it, including ALL of its "tricks",
    including things like this "batch processing".

    You seem to be assuming that there is some "Operationg System"
    outside the Decider - Input structure, but there isn't, at least not
    one that can affect the answer of the problem.

    I spent 12 hours a day for the last 10 days getting the copy the input
    working. When H(D,D) (in decidability decider mode) detects that its
    input is in the well defined set of pathological inputs it returns 0
    indicating that its input is undecidable. The batch file that invoked H
    then knows to invoke H1(D,D) to correctly report that D(D) halts.

    This solution does seem to work correctly on every conventional proof in
    every textbook.


    So, what is the definition of that "Well Definde Set"? or is this just another of your moronic oxymorons.


    A set is a well-defined collection of objects called elements or members
    of the set. If x is a member of the set S, we write x ∈ S, and if x is a
    not member of the set S, we write x ∈ S Here, well-defined means that
    any given object must either be an element of the set, or not be an
    element of the set.
    https://www.math.uvic.ca/faculty/gmacgill/guide/sets.pdf

    My definition of well-defined set is that it includes and excludes a
    body of finite string pairs such that the second element of this pair
    that can be encoded in an infinite number of different ways that cannot
    even be foreseen in advance, all of which have the property of a
    pathological relationship to their decider.

    Since my system requires that the behavior of the input must be
    considered in making this assessment it is a semantic property.

    Note, H can't have "Modes" that are externally controlled, as it has no
    input to control that, it is just a decider that is given an input to
    decide on.


    Technically you are correct on this when construed as computable
    functions.

    If you have some "fuller" algorithm you use to decide that uses the sub-function H to do a step, then D needs to be built on that fuller algorithm, as THAT is what you are actually claiming to be your halt
    decider.


    It is only a matter of returning 1 for non-halting and halting inputs
    and returning 0 for pathological inputs, thus the actual computation is identical except for a single bit of the return value.

    We could also simply run the input where H(D,D) != H1(D,D) means
    pathological input, thus accept the H1(D,D) value as correct.

    I guess you are just making it painfully obvious that you don't
    understand the nature of the problem you claim to be working on.


    I foresaw this objection before you made it.

    So, since it seems that you have some sort of "batch file" that is your actual decider, you need to show how you have a program invoke that and
    do tha tin D. If you can't, you are just admitting that you are not
    working on the actual problem defined, but are playing games in the sub-Turing Complete versions of the problem, which has many known
    solutions.


    Batch files and Bash scripts can take different paths depending on the
    return value of their executable.

    It seems that you just wasted 120 hours of work and just proved that you
    are totally ignorant of the problem and don't know what you are talking aobut.

    You will say that no matter how correct that I prove to be.

    --
    Copyright 2023 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 Sun Jul 2 22:41:03 2023
    XPost: comp.theory, sci.logic

    On 7/2/23 10:01 PM, olcott wrote:
    On 7/2/2023 8:40 PM, Richard Damon wrote:
    On 7/2/23 8:45 PM, olcott wrote:
    A single H can consistently correctly determine whether or not its input >>> is pathological relative to itself. When H(D,D) is invoked in
    decidability decider mode determines that D is pathological relative to
    itself this enables a batch file to invoke H1(D,D) to get the actual
    behavior of the directly executed D(D). H1 is identical to H except for
    the pathological relationship to H.



    And does an input D that uses this FULL algorithm give your algorithm
    problems?

    Since H(D,D) will (apparently) determine that the input is
    pathological, and thus defer to H1(D,D), then when we actually run D,
    appearently it will get that same answer from H1 and do the opposite
    of it, and thus H1 will be wrong.

    Remember, the "Pathological" program is built on a copy of the ACTUAL
    program that you ask to decide on it, including ALL of its "tricks",
    including things like this "batch processing".

    You seem to be assuming that there is some "Operationg System" outside
    the Decider - Input structure, but there isn't, at least not one that
    can affect the answer of the problem.

    I spent 12 hours a day for the last 10 days getting the copy the input working. When H(D,D) (in decidability decider mode) detects that its
    input is in the well defined set of pathological inputs it returns 0 indicating that its input is undecidable. The batch file that invoked H
    then knows to invoke H1(D,D) to correctly report that D(D) halts.

    This solution does seem to work correctly on every conventional proof in every textbook.


    So, did you make your "conventional proof" template actually use a copy
    of your ACTUAL decider (which seems to be your "batch file" not the C
    funciton H), or are you just admitting that you wasted 120 hours looking
    at the wrong thing because you have made yourself intentionally ignorant
    of the subject so you don't understand what you are trying to do.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to olcott on Sun Jul 2 22:54:57 2023
    XPost: comp.theory, sci.logic

    On 7/2/2023 10:10 PM, olcott wrote:
    On 7/2/2023 9:37 PM, Richard Damon wrote:
    On 7/2/23 10:01 PM, olcott wrote:
    On 7/2/2023 8:40 PM, Richard Damon wrote:
    On 7/2/23 8:45 PM, olcott wrote:
    A single H can consistently correctly determine whether or not its
    input
    is pathological relative to itself. When H(D,D) is invoked in
    decidability decider mode determines that D is pathological
    relative to
    itself this enables a batch file to invoke H1(D,D) to get the actual >>>>> behavior of the directly executed D(D). H1 is identical to H except
    for
    the pathological relationship to H.



    And does an input D that uses this FULL algorithm give your
    algorithm problems?

    Since H(D,D) will (apparently) determine that the input is
    pathological, and thus defer to H1(D,D), then when we actually run
    D, appearently it will get that same answer from H1 and do the
    opposite of it, and thus H1 will be wrong.

    Remember, the "Pathological" program is built on a copy of the
    ACTUAL program that you ask to decide on it, including ALL of its
    "tricks", including things like this "batch processing".

    You seem to be assuming that there is some "Operationg System"
    outside the Decider - Input structure, but there isn't, at least not
    one that can affect the answer of the problem.

    I spent 12 hours a day for the last 10 days getting the copy the input
    working. When H(D,D) (in decidability decider mode) detects that its
    input is in the well defined set of pathological inputs it returns 0
    indicating that its input is undecidable. The batch file that invoked H
    then knows to invoke H1(D,D) to correctly report that D(D) halts.

    This solution does seem to work correctly on every conventional proof in >>> every textbook.


    So, what is the definition of that "Well Definde Set"? or is this just
    another of your moronic oxymorons.


    A set is a well-defined collection of objects called elements or members
    of the set. If x is a member of the set S, we write x ∈ S, and if x is a not member of the set S, we write x ∈ S Here, well-defined means that
    any given object must either be an element of the set, or not be an
    element of the set.
    https://www.math.uvic.ca/faculty/gmacgill/guide/sets.pdf

    My definition of well-defined set is that it includes and excludes a
    body of finite string pairs such that the second element of this pair
    that can be encoded in an infinite number of different ways that cannot
    even be foreseen in advance, all of which have the property of a
    pathological relationship to their decider.

    Since my system requires that the behavior of the input must be
    considered in making this assessment it is a semantic property.

    Note, H can't have "Modes" that are externally controlled, as it has
    no input to control that, it is just a decider that is given an input
    to decide on.


    Technically you are correct on this when construed as computable
    functions.

    If you have some "fuller" algorithm you use to decide that uses the
    sub-function H to do a step, then D needs to be built on that fuller
    algorithm, as THAT is what you are actually claiming to be your halt
    decider.


    It is only a matter of returning 1 for non-halting and halting inputs
    and returning 0 for pathological inputs, thus the actual computation is identical except for a single bit of the return value.

    We could also simply run the input where H(D,D) != H1(D,D) means
    pathological input, thus accept the H1(D,D) value as correct.


    u32 H_DD = H(D,D);
    u32 H1_DD = H1(D,D);
    if (H_DD != H1_DD)
    Output("H1(D,D) correct halt status is:", H1_DD);

    H1(D,D) correct halt status is:1


    I guess you are just making it painfully obvious that you don't
    understand the nature of the problem you claim to be working on.


    I foresaw this objection before you made it.

    So, since it seems that you have some sort of "batch file" that is
    your actual decider, you need to show how you have a program invoke
    that and do tha tin D. If you can't, you are just admitting that you
    are not working on the actual problem defined, but are playing games
    in the sub-Turing Complete versions of the problem, which has many
    known solutions.


    Batch files and Bash scripts can take different paths depending on the
    return value of their executable.

    It seems that you just wasted 120 hours of work and just proved that
    you are totally ignorant of the problem and don't know what you are
    talking aobut.

    You will say that no matter how correct that I prove to be.


    --
    Copyright 2023 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 Mon Jul 3 09:13:50 2023
    XPost: comp.theory, sci.logic

    On 7/2/23 11:10 PM, olcott wrote:
    On 7/2/2023 9:37 PM, Richard Damon wrote:
    On 7/2/23 10:01 PM, olcott wrote:
    On 7/2/2023 8:40 PM, Richard Damon wrote:
    On 7/2/23 8:45 PM, olcott wrote:
    A single H can consistently correctly determine whether or not its
    input
    is pathological relative to itself. When H(D,D) is invoked in
    decidability decider mode determines that D is pathological
    relative to
    itself this enables a batch file to invoke H1(D,D) to get the actual >>>>> behavior of the directly executed D(D). H1 is identical to H except
    for
    the pathological relationship to H.



    And does an input D that uses this FULL algorithm give your
    algorithm problems?

    Since H(D,D) will (apparently) determine that the input is
    pathological, and thus defer to H1(D,D), then when we actually run
    D, appearently it will get that same answer from H1 and do the
    opposite of it, and thus H1 will be wrong.

    Remember, the "Pathological" program is built on a copy of the
    ACTUAL program that you ask to decide on it, including ALL of its
    "tricks", including things like this "batch processing".

    You seem to be assuming that there is some "Operationg System"
    outside the Decider - Input structure, but there isn't, at least not
    one that can affect the answer of the problem.

    I spent 12 hours a day for the last 10 days getting the copy the input
    working. When H(D,D) (in decidability decider mode) detects that its
    input is in the well defined set of pathological inputs it returns 0
    indicating that its input is undecidable. The batch file that invoked H
    then knows to invoke H1(D,D) to correctly report that D(D) halts.

    This solution does seem to work correctly on every conventional proof in >>> every textbook.


    So, what is the definition of that "Well Definde Set"? or is this just
    another of your moronic oxymorons.


    A set is a well-defined collection of objects called elements or members
    of the set. If x is a member of the set S, we write x ∈ S, and if x is a not member of the set S, we write x ∈ S Here, well-defined means that
    any given object must either be an element of the set, or not be an
    element of the set.
    https://www.math.uvic.ca/faculty/gmacgill/guide/sets.pdf

    My definition of well-defined set is that it includes and excludes a
    body of finite string pairs such that the second element of this pair
    that can be encoded in an infinite number of different ways that cannot
    even be foreseen in advance, all of which have the property of a
    pathological relationship to their decider.

    And how do you detect this? You just admitted that there are an infinite
    number of them, so you can't just string compare to detect it.


    Since my system requires that the behavior of the input must be
    considered in making this assessment it is a semantic property.

    But you still haven't described how you detect it.



    Note, H can't have "Modes" that are externally controlled, as it has
    no input to control that, it is just a decider that is given an input
    to decide on.


    Technically you are correct on this when construed as computable
    functions.


    And computations are computable functions. If the function isn't
    computable, by definition no program exists that computes it.

    Deciders are, by definition, Computations, so again, by definition,
    don't have "modes" (except as defined by an actual input).

    All this shows is that you ar playing games with words, and have
    deceived yourself.

    If H has "Modes", it isn't the Decider, so showing that you can get the
    correct answer for the D built on IT is meaningless, you need to show
    you can get the correct answer for the D built on your actual decider,
    not just a piece of it.

    If you have some "fuller" algorithm you use to decide that uses the
    sub-function H to do a step, then D needs to be built on that fuller
    algorithm, as THAT is what you are actually claiming to be your halt
    decider.


    It is only a matter of returning 1 for non-halting and halting inputs
    and returning 0 for pathological inputs, thus the actual computation is identical except for a single bit of the return value.

    We could also simply run the input where H(D,D) != H1(D,D) means
    pathological input, thus accept the H1(D,D) value as correct.

    You need to make clear what type of decider you are defining. If a Halt Decider, then there is no allowed change of answer.

    IF you are trying to refute Rice, then you need to clearly define the
    property that you are going to use, which your above definition requires
    a FIXED H/H1 to be defined, and that the property is actually Semantic.
    The fact that it is defined by executing your deciders is NOT enough.

    One important thing that you seem to be missing is that Rice's Theorem
    is NOT about "Programs" and their behavior, but about Functions and
    languages, and their ability to be recognized by a program.

    You still need to show that your property is semantic, and the fact that
    you can determine that value without needing to actually run the input
    shows that it isn't.


    I guess you are just making it painfully obvious that you don't
    understand the nature of the problem you claim to be working on.


    I foresaw this objection before you made it.

    But didn't answer it.


    So, since it seems that you have some sort of "batch file" that is
    your actual decider, you need to show how you have a program invoke
    that and do tha tin D. If you can't, you are just admitting that you
    are not working on the actual problem defined, but are playing games
    in the sub-Turing Complete versions of the problem, which has many
    known solutions.


    Batch files and Bash scripts can take different paths depending on the
    return value of their executable.

    Right, but now the "Decider" is a "Batch Script" so the program D must
    be able to do the equivalent of that batch script, or you system doesn't acccept a Turing Complete set.


    It seems that you just wasted 120 hours of work and just proved that
    you are totally ignorant of the problem and don't know what you are
    talking aobut.

    You will say that no matter how correct that I prove to be.


    Only when I show you are wrong. Actually try to answer my objections

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Mon Jul 3 09:14:07 2023
    XPost: comp.theory, sci.logic

    On 7/2/23 10:48 PM, olcott wrote:
    On 7/2/2023 9:41 PM, Richard Damon wrote:
    On 7/2/23 10:01 PM, olcott wrote:
    On 7/2/2023 8:40 PM, Richard Damon wrote:
    On 7/2/23 8:45 PM, olcott wrote:
    A single H can consistently correctly determine whether or not its
    input
    is pathological relative to itself. When H(D,D) is invoked in
    decidability decider mode determines that D is pathological
    relative to
    itself this enables a batch file to invoke H1(D,D) to get the actual >>>>> behavior of the directly executed D(D). H1 is identical to H except
    for
    the pathological relationship to H.



    And does an input D that uses this FULL algorithm give your
    algorithm problems?

    Since H(D,D) will (apparently) determine that the input is
    pathological, and thus defer to H1(D,D), then when we actually run
    D, appearently it will get that same answer from H1 and do the
    opposite of it, and thus H1 will be wrong.

    Remember, the "Pathological" program is built on a copy of the
    ACTUAL program that you ask to decide on it, including ALL of its
    "tricks", including things like this "batch processing".

    You seem to be assuming that there is some "Operationg System"
    outside the Decider - Input structure, but there isn't, at least not
    one that can affect the answer of the problem.

    I spent 12 hours a day for the last 10 days getting the copy the input
    working. When H(D,D) (in decidability decider mode) detects that its
    input is in the well defined set of pathological inputs it returns 0
    indicating that its input is undecidable. The batch file that invoked H
    then knows to invoke H1(D,D) to correctly report that D(D) halts.

    This solution does seem to work correctly on every conventional proof in >>> every textbook.


    So, did you make your "conventional proof" template actually use a
    copy of your ACTUAL decider (which seems to be your "batch file" not
    the C funciton H), or are you just admitting that you wasted 120 hours
    looking at the wrong thing because you have made yourself
    intentionally ignorant of the subject so you don't understand what you
    are trying to do.

    New_D copies its input and simulates its input with its input.
    It never sees New_H.


    Why not? Since New_H is the thing that is considered the "Correct Halt Decider", New_D needs to be built on it.

    You keep on forgetting that the proof says we create a specific input
    for the given halt decider claimed to be correct, and the only halt
    decider that input is claimed to not be decidable with is that one.

    SHowing that New_H can answer for the input designed on H means nothing,
    you need to show that it can handle the input designed for itself.

    THAT is where the actual self-reference occurs, that there exists within
    the set of "any program" a program built on the decider in this manner.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Richard Damon on Mon Jul 3 08:47:39 2023
    XPost: comp.theory, sci.logic

    On 7/3/2023 8:14 AM, Richard Damon wrote:
    On 7/2/23 10:48 PM, olcott wrote:
    On 7/2/2023 9:41 PM, Richard Damon wrote:
    On 7/2/23 10:01 PM, olcott wrote:
    On 7/2/2023 8:40 PM, Richard Damon wrote:
    On 7/2/23 8:45 PM, olcott wrote:
    A single H can consistently correctly determine whether or not its >>>>>> input
    is pathological relative to itself. When H(D,D) is invoked in
    decidability decider mode determines that D is pathological
    relative to
    itself this enables a batch file to invoke H1(D,D) to get the actual >>>>>> behavior of the directly executed D(D). H1 is identical to H
    except for
    the pathological relationship to H.



    And does an input D that uses this FULL algorithm give your
    algorithm problems?

    Since H(D,D) will (apparently) determine that the input is
    pathological, and thus defer to H1(D,D), then when we actually run
    D, appearently it will get that same answer from H1 and do the
    opposite of it, and thus H1 will be wrong.

    Remember, the "Pathological" program is built on a copy of the
    ACTUAL program that you ask to decide on it, including ALL of its
    "tricks", including things like this "batch processing".

    You seem to be assuming that there is some "Operationg System"
    outside the Decider - Input structure, but there isn't, at least
    not one that can affect the answer of the problem.

    I spent 12 hours a day for the last 10 days getting the copy the input >>>> working. When H(D,D) (in decidability decider mode) detects that its
    input is in the well defined set of pathological inputs it returns 0
    indicating that its input is undecidable. The batch file that invoked H >>>> then knows to invoke H1(D,D) to correctly report that D(D) halts.

    This solution does seem to work correctly on every conventional
    proof in
    every textbook.


    So, did you make your "conventional proof" template actually use a
    copy of your ACTUAL decider (which seems to be your "batch file" not
    the C funciton H), or are you just admitting that you wasted 120
    hours looking at the wrong thing because you have made yourself
    intentionally ignorant of the subject so you don't understand what
    you are trying to do.

    New_D copies its input and simulates its input with its input.
    It never sees New_H.


    Why not? Since New_H is the thing that is considered the "Correct Halt Decider", New_D needs to be built on it.


    New_H is embedded within New_D (as its middle states) just the
    way it is supposed to be. The question is: Does New_H(New_H) halt?

    The only difference at the source code level is:
    (a) New_H copies its input, thus takes one param.
    (b) New_H has an infinite loop at its accept state.

    You keep on forgetting that the proof says we create a specific input
    for the given halt decider claimed to be correct, and the only halt
    decider that input is claimed to not be decidable with is that one.

    SHowing that New_H can answer for the input designed on H means nothing,
    you need to show that it can handle the input designed for itself.

    THAT is where the actual self-reference occurs, that there exists within
    the set of "any program" a program built on the decider in this manner.

    --
    Copyright 2023 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 Mon Jul 3 10:24:07 2023
    XPost: comp.theory, sci.logic

    On 7/3/23 9:47 AM, olcott wrote:
    On 7/3/2023 8:14 AM, Richard Damon wrote:
    On 7/2/23 10:48 PM, olcott wrote:
    On 7/2/2023 9:41 PM, Richard Damon wrote:
    On 7/2/23 10:01 PM, olcott wrote:
    On 7/2/2023 8:40 PM, Richard Damon wrote:
    On 7/2/23 8:45 PM, olcott wrote:
    A single H can consistently correctly determine whether or not
    its input
    is pathological relative to itself. When H(D,D) is invoked in
    decidability decider mode determines that D is pathological
    relative to
    itself this enables a batch file to invoke H1(D,D) to get the actual >>>>>>> behavior of the directly executed D(D). H1 is identical to H
    except for
    the pathological relationship to H.



    And does an input D that uses this FULL algorithm give your
    algorithm problems?

    Since H(D,D) will (apparently) determine that the input is
    pathological, and thus defer to H1(D,D), then when we actually run >>>>>> D, appearently it will get that same answer from H1 and do the
    opposite of it, and thus H1 will be wrong.

    Remember, the "Pathological" program is built on a copy of the
    ACTUAL program that you ask to decide on it, including ALL of its
    "tricks", including things like this "batch processing".

    You seem to be assuming that there is some "Operationg System"
    outside the Decider - Input structure, but there isn't, at least
    not one that can affect the answer of the problem.

    I spent 12 hours a day for the last 10 days getting the copy the input >>>>> working. When H(D,D) (in decidability decider mode) detects that its >>>>> input is in the well defined set of pathological inputs it returns 0 >>>>> indicating that its input is undecidable. The batch file that
    invoked H
    then knows to invoke H1(D,D) to correctly report that D(D) halts.

    This solution does seem to work correctly on every conventional
    proof in
    every textbook.


    So, did you make your "conventional proof" template actually use a
    copy of your ACTUAL decider (which seems to be your "batch file" not
    the C funciton H), or are you just admitting that you wasted 120
    hours looking at the wrong thing because you have made yourself
    intentionally ignorant of the subject so you don't understand what
    you are trying to do.

    New_D copies its input and simulates its input with its input.
    It never sees New_H.


    Why not? Since New_H is the thing that is considered the "Correct Halt
    Decider", New_D needs to be built on it.


    New_H is embedded within New_D (as its middle states) just the
    way it is supposed to be. The question is: Does New_H(New_H) halt?

    The only difference at the source code level is:
    (a) New_H copies its input, thus takes one param.
    (b) New_H has an infinite loop at its accept state.

    So, how is New_H a halt decider then?

    Or are you just being deceptive about what problem you are solving again.

    If New_H is about your 'Rice' problem machine, I showed why your
    property wasn't semantic, so doesn't disprove the Rice proofs.

    Remember, the definition based on "executing" are based on executing the machine described on the input, NOT on executing the decider.

    After all, of course a property based on the execution decider is decidable.

    You seem to be just building a great big argument out of strawmen, and
    Red Herring, and forgetting the actual problem you claim to be working on.


    You keep on forgetting that the proof says we create a specific input
    for the given halt decider claimed to be correct, and the only halt
    decider that input is claimed to not be decidable with is that one.

    SHowing that New_H can answer for the input designed on H means
    nothing, you need to show that it can handle the input designed for
    itself.

    THAT is where the actual self-reference occurs, that there exists
    within the set of "any program" a program built on the decider in this
    manner.


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Richard Damon on Mon Jul 3 09:42:14 2023
    XPost: comp.theory, sci.logic

    On 7/3/2023 8:13 AM, Richard Damon wrote:
    On 7/2/23 11:10 PM, olcott wrote:
    On 7/2/2023 9:37 PM, Richard Damon wrote:
    On 7/2/23 10:01 PM, olcott wrote:
    On 7/2/2023 8:40 PM, Richard Damon wrote:
    On 7/2/23 8:45 PM, olcott wrote:
    A single H can consistently correctly determine whether or not its >>>>>> input
    is pathological relative to itself. When H(D,D) is invoked in
    decidability decider mode determines that D is pathological
    relative to
    itself this enables a batch file to invoke H1(D,D) to get the actual >>>>>> behavior of the directly executed D(D). H1 is identical to H
    except for
    the pathological relationship to H.



    And does an input D that uses this FULL algorithm give your
    algorithm problems?

    Since H(D,D) will (apparently) determine that the input is
    pathological, and thus defer to H1(D,D), then when we actually run
    D, appearently it will get that same answer from H1 and do the
    opposite of it, and thus H1 will be wrong.

    Remember, the "Pathological" program is built on a copy of the
    ACTUAL program that you ask to decide on it, including ALL of its
    "tricks", including things like this "batch processing".

    You seem to be assuming that there is some "Operationg System"
    outside the Decider - Input structure, but there isn't, at least
    not one that can affect the answer of the problem.

    I spent 12 hours a day for the last 10 days getting the copy the input >>>> working. When H(D,D) (in decidability decider mode) detects that its
    input is in the well defined set of pathological inputs it returns 0
    indicating that its input is undecidable. The batch file that invoked H >>>> then knows to invoke H1(D,D) to correctly report that D(D) halts.

    This solution does seem to work correctly on every conventional
    proof in
    every textbook.


    So, what is the definition of that "Well Definde Set"? or is this
    just another of your moronic oxymorons.


    A set is a well-defined collection of objects called elements or
    members of the set. If x is a member of the set S, we write x ∈ S, and
    if x is a not member of the set S, we write x ∈ S Here, well-defined
    means that any given object must either be an element of the set, or
    not be an element of the set.
    https://www.math.uvic.ca/faculty/gmacgill/guide/sets.pdf

    My definition of well-defined set is that it includes and excludes a
    body of finite string pairs such that the second element of this pair
    that can be encoded in an infinite number of different ways that cannot
    even be foreseen in advance, all of which have the property of a
    pathological relationship to their decider.

    And how do you detect this? You just admitted that there are an infinite number of them, so you can't just string compare to detect it.


    Since my system requires that the behavior of the input must be
    considered in making this assessment it is a semantic property.

    But you still haven't described how you detect it.



    Note, H can't have "Modes" that are externally controlled, as it has
    no input to control that, it is just a decider that is given an input
    to decide on.


    Technically you are correct on this when construed as computable
    functions.


    And computations are computable functions. If the function isn't
    computable, by definition no program exists that computes it.

    Deciders are, by definition, Computations, so again, by definition,
    don't have "modes" (except as defined by an actual input).

    All this shows is that you ar playing games with words, and have
    deceived yourself.

    If H has "Modes", it isn't the Decider, so showing that you can get the correct answer for the D built on IT is meaningless, you need to show
    you can get the correct answer for the D built on your actual decider,
    not just a piece of it.

    If you have some "fuller" algorithm you use to decide that uses the
    sub-function H to do a step, then D needs to be built on that fuller
    algorithm, as THAT is what you are actually claiming to be your halt
    decider.


    It is only a matter of returning 1 for non-halting and halting inputs
    and returning 0 for pathological inputs, thus the actual computation is
    identical except for a single bit of the return value.

    We could also simply run the input where H(D,D) != H1(D,D) means
    pathological input, thus accept the H1(D,D) value as correct.

    You need to make clear what type of decider you are defining. If a Halt Decider, then there is no allowed change of answer.

    IF you are trying to refute Rice, then you need to clearly define the property that you are going to use, which your above definition requires
    a FIXED H/H1 to be defined, and that the property is actually Semantic.
    The fact that it is defined by executing your deciders is NOT enough.

    One important thing that you seem to be missing is that Rice's Theorem
    is NOT about "Programs" and their behavior, but about Functions and languages, and their ability to be recognized by a program.

    You still need to show that your property is semantic, and the fact that
    you can determine that value without needing to actually run the input
    shows that it isn't.


    I guess you are just making it painfully obvious that you don't
    understand the nature of the problem you claim to be working on.


    I foresaw this objection before you made it.

    But didn't answer it.


    So, since it seems that you have some sort of "batch file" that is
    your actual decider, you need to show how you have a program invoke
    that and do tha tin D. If you can't, you are just admitting that you
    are not working on the actual problem defined, but are playing games
    in the sub-Turing Complete versions of the problem, which has many
    known solutions.


    Batch files and Bash scripts can take different paths depending on the
    return value of their executable.

    Right, but now the "Decider" is a "Batch Script" so the program D must
    be able to do the equivalent of that batch script, or you system doesn't acccept a Turing Complete set.


    It seems that you just wasted 120 hours of work and just proved that
    you are totally ignorant of the problem and don't know what you are
    talking aobut.

    You will say that no matter how correct that I prove to be.


    Only when I show you are wrong. Actually try to answer my objections


    What about a three valued decider?
    0=undecidable
    1=halting
    2=not halting

    --
    Copyright 2023 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 olcott@21:1/5 to Richard Damon on Mon Jul 3 09:45:57 2023
    XPost: comp.theory, sci.logic

    On 7/3/2023 9:24 AM, Richard Damon wrote:
    On 7/3/23 9:47 AM, olcott wrote:
    On 7/3/2023 8:14 AM, Richard Damon wrote:
    On 7/2/23 10:48 PM, olcott wrote:
    On 7/2/2023 9:41 PM, Richard Damon wrote:
    On 7/2/23 10:01 PM, olcott wrote:
    On 7/2/2023 8:40 PM, Richard Damon wrote:
    On 7/2/23 8:45 PM, olcott wrote:
    A single H can consistently correctly determine whether or not >>>>>>>> its input
    is pathological relative to itself. When H(D,D) is invoked in
    decidability decider mode determines that D is pathological
    relative to
    itself this enables a batch file to invoke H1(D,D) to get the
    actual
    behavior of the directly executed D(D). H1 is identical to H
    except for
    the pathological relationship to H.



    And does an input D that uses this FULL algorithm give your
    algorithm problems?

    Since H(D,D) will (apparently) determine that the input is
    pathological, and thus defer to H1(D,D), then when we actually
    run D, appearently it will get that same answer from H1 and do
    the opposite of it, and thus H1 will be wrong.

    Remember, the "Pathological" program is built on a copy of the
    ACTUAL program that you ask to decide on it, including ALL of its >>>>>>> "tricks", including things like this "batch processing".

    You seem to be assuming that there is some "Operationg System"
    outside the Decider - Input structure, but there isn't, at least >>>>>>> not one that can affect the answer of the problem.

    I spent 12 hours a day for the last 10 days getting the copy the
    input
    working. When H(D,D) (in decidability decider mode) detects that its >>>>>> input is in the well defined set of pathological inputs it returns 0 >>>>>> indicating that its input is undecidable. The batch file that
    invoked H
    then knows to invoke H1(D,D) to correctly report that D(D) halts.

    This solution does seem to work correctly on every conventional
    proof in
    every textbook.


    So, did you make your "conventional proof" template actually use a
    copy of your ACTUAL decider (which seems to be your "batch file"
    not the C funciton H), or are you just admitting that you wasted
    120 hours looking at the wrong thing because you have made yourself
    intentionally ignorant of the subject so you don't understand what
    you are trying to do.

    New_D copies its input and simulates its input with its input.
    It never sees New_H.


    Why not? Since New_H is the thing that is considered the "Correct
    Halt Decider", New_D needs to be built on it.


    New_H is embedded within New_D (as its middle states) just the
    way it is supposed to be. The question is: Does New_H(New_H) halt?

    The only difference at the source code level is:
    (a) New_H copies its input, thus takes one param.
    (b) New_H has an infinite loop at its accept state.

    So, how is New_H a halt decider then?

    typo
    The only difference at the source code level is:
    (a) New_D copies its input, thus takes one param.
    (b) New_D has an infinite loop at its accept state.
    Other than that (at the source-code level) New_D is exactly New_H


    --
    Copyright 2023 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 olcott@21:1/5 to Richard Damon on Mon Jul 3 10:10:13 2023
    XPost: comp.theory, sci.logic

    On 7/3/2023 8:14 AM, Richard Damon wrote:
    On 7/2/23 11:54 PM, olcott wrote:
    On 7/2/2023 10:10 PM, olcott wrote:
    On 7/2/2023 9:37 PM, Richard Damon wrote:
    On 7/2/23 10:01 PM, olcott wrote:
    On 7/2/2023 8:40 PM, Richard Damon wrote:
    On 7/2/23 8:45 PM, olcott wrote:
    A single H can consistently correctly determine whether or not
    its input
    is pathological relative to itself. When H(D,D) is invoked in
    decidability decider mode determines that D is pathological
    relative to
    itself this enables a batch file to invoke H1(D,D) to get the actual >>>>>>> behavior of the directly executed D(D). H1 is identical to H
    except for
    the pathological relationship to H.



    And does an input D that uses this FULL algorithm give your
    algorithm problems?

    Since H(D,D) will (apparently) determine that the input is
    pathological, and thus defer to H1(D,D), then when we actually run >>>>>> D, appearently it will get that same answer from H1 and do the
    opposite of it, and thus H1 will be wrong.

    Remember, the "Pathological" program is built on a copy of the
    ACTUAL program that you ask to decide on it, including ALL of its
    "tricks", including things like this "batch processing".

    You seem to be assuming that there is some "Operationg System"
    outside the Decider - Input structure, but there isn't, at least
    not one that can affect the answer of the problem.

    I spent 12 hours a day for the last 10 days getting the copy the input >>>>> working. When H(D,D) (in decidability decider mode) detects that its >>>>> input is in the well defined set of pathological inputs it returns 0 >>>>> indicating that its input is undecidable. The batch file that
    invoked H
    then knows to invoke H1(D,D) to correctly report that D(D) halts.

    This solution does seem to work correctly on every conventional
    proof in
    every textbook.


    So, what is the definition of that "Well Definde Set"? or is this
    just another of your moronic oxymorons.


    A set is a well-defined collection of objects called elements or
    members of the set. If x is a member of the set S, we write x ∈ S,
    and if x is a not member of the set S, we write x ∈ S Here,
    well-defined means that any given object must either be an element of
    the set, or not be an element of the set.
    https://www.math.uvic.ca/faculty/gmacgill/guide/sets.pdf

    My definition of well-defined set is that it includes and excludes a
    body of finite string pairs such that the second element of this pair
    that can be encoded in an infinite number of different ways that cannot
    even be foreseen in advance, all of which have the property of a
    pathological relationship to their decider.

    Since my system requires that the behavior of the input must be
    considered in making this assessment it is a semantic property.

    Note, H can't have "Modes" that are externally controlled, as it has
    no input to control that, it is just a decider that is given an
    input to decide on.


    Technically you are correct on this when construed as computable
    functions.

    If you have some "fuller" algorithm you use to decide that uses the
    sub-function H to do a step, then D needs to be built on that fuller
    algorithm, as THAT is what you are actually claiming to be your halt
    decider.


    It is only a matter of returning 1 for non-halting and halting inputs
    and returning 0 for pathological inputs, thus the actual computation is
    identical except for a single bit of the return value.

    We could also simply run the input where H(D,D) != H1(D,D) means
    pathological input, thus accept the H1(D,D) value as correct.


       u32 H_DD  = H(D,D);
       u32 H1_DD = H1(D,D);
       if (H_DD != H1_DD)
         Output("H1(D,D) correct halt status is:", H1_DD);

    H1(D,D) correct halt status is:1

    So, what returns the actual results of the Halt decision?

    Remember, THAT is what D will call, not H or H1, since neither, by themselves, is a halt decider.

    That seems to mean that your ACTUAL Halt Decider HD(P, m) would be
    something like:

    HD(P, m) {
      u32 H_DD = H(P, m);
      u32 H1_DD = H1(P, m);
      return (H_DD == H1_DD) ? H_DD : H1_DD;
    }

    and

    D is defined something like:
    D(P) {
      if(HD(P,P)) {
        while(1) ;
      }
    }

    Which still gives the wrong answer.


    You seem to be forgetting what a Halt Decider needs to be.

    At the Turing machine level any D can make it impossible for a
    particular H to be unable to correctly report on the behavior of the
    directly executed D(D). Because D is a fixed constant finite string it
    cannot dynamically reconfigure itself to fool a different H.


    --
    Copyright 2023 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 Mon Jul 3 11:35:15 2023
    XPost: comp.theory, sci.logic

    On 7/3/23 10:42 AM, olcott wrote:
    On 7/3/2023 8:13 AM, Richard Damon wrote:
    On 7/2/23 11:10 PM, olcott wrote:

    Only when I show you are wrong. Actually try to answer my objections


    What about a three valued decider?
    0=undecidable
    1=halting
    2=not halting


    Doesn't meet the definition of a Halt Decider.

    After all, ALL inputs to H represent a computation that either Halts or
    Not, so "Undecidable" isn't a correct answer for the behavior of that
    machine.

    So, all you are doing is showing that you don't understand that actual
    problem you claim to be solving.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Richard Damon on Mon Jul 3 10:41:50 2023
    XPost: comp.theory, sci.logic

    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 11:10 AM, olcott wrote:
    On 7/3/2023 8:14 AM, Richard Damon wrote:
    On 7/2/23 11:54 PM, olcott wrote:
    On 7/2/2023 10:10 PM, olcott wrote:
    On 7/2/2023 9:37 PM, Richard Damon wrote:
    On 7/2/23 10:01 PM, olcott wrote:
    On 7/2/2023 8:40 PM, Richard Damon wrote:
    On 7/2/23 8:45 PM, olcott wrote:
    A single H can consistently correctly determine whether or not >>>>>>>>> its input
    is pathological relative to itself. When H(D,D) is invoked in >>>>>>>>> decidability decider mode determines that D is pathological
    relative to
    itself this enables a batch file to invoke H1(D,D) to get the >>>>>>>>> actual
    behavior of the directly executed D(D). H1 is identical to H >>>>>>>>> except for
    the pathological relationship to H.



    And does an input D that uses this FULL algorithm give your
    algorithm problems?

    Since H(D,D) will (apparently) determine that the input is
    pathological, and thus defer to H1(D,D), then when we actually >>>>>>>> run D, appearently it will get that same answer from H1 and do >>>>>>>> the opposite of it, and thus H1 will be wrong.

    Remember, the "Pathological" program is built on a copy of the >>>>>>>> ACTUAL program that you ask to decide on it, including ALL of
    its "tricks", including things like this "batch processing".

    You seem to be assuming that there is some "Operationg System" >>>>>>>> outside the Decider - Input structure, but there isn't, at least >>>>>>>> not one that can affect the answer of the problem.

    I spent 12 hours a day for the last 10 days getting the copy the >>>>>>> input
    working. When H(D,D) (in decidability decider mode) detects that its >>>>>>> input is in the well defined set of pathological inputs it returns 0 >>>>>>> indicating that its input is undecidable. The batch file that
    invoked H
    then knows to invoke H1(D,D) to correctly report that D(D) halts. >>>>>>>
    This solution does seem to work correctly on every conventional
    proof in
    every textbook.


    So, what is the definition of that "Well Definde Set"? or is this
    just another of your moronic oxymorons.


    A set is a well-defined collection of objects called elements or
    members of the set. If x is a member of the set S, we write x ∈ S, >>>>> and if x is a not member of the set S, we write x ∈ S Here,
    well-defined means that any given object must either be an element
    of the set, or not be an element of the set.
    https://www.math.uvic.ca/faculty/gmacgill/guide/sets.pdf

    My definition of well-defined set is that it includes and excludes a >>>>> body of finite string pairs such that the second element of this pair >>>>> that can be encoded in an infinite number of different ways that
    cannot
    even be foreseen in advance, all of which have the property of a
    pathological relationship to their decider.

    Since my system requires that the behavior of the input must be
    considered in making this assessment it is a semantic property.

    Note, H can't have "Modes" that are externally controlled, as it
    has no input to control that, it is just a decider that is given
    an input to decide on.


    Technically you are correct on this when construed as computable
    functions.

    If you have some "fuller" algorithm you use to decide that uses
    the sub-function H to do a step, then D needs to be built on that
    fuller algorithm, as THAT is what you are actually claiming to be
    your halt decider.


    It is only a matter of returning 1 for non-halting and halting inputs >>>>> and returning 0 for pathological inputs, thus the actual
    computation is
    identical except for a single bit of the return value.

    We could also simply run the input where H(D,D) != H1(D,D) means
    pathological input, thus accept the H1(D,D) value as correct.


       u32 H_DD  = H(D,D);
       u32 H1_DD = H1(D,D);
       if (H_DD != H1_DD)
         Output("H1(D,D) correct halt status is:", H1_DD);

    H1(D,D) correct halt status is:1

    So, what returns the actual results of the Halt decision?

    Remember, THAT is what D will call, not H or H1, since neither, by
    themselves, is a halt decider.

    That seems to mean that your ACTUAL Halt Decider HD(P, m) would be
    something like:

    HD(P, m) {
       u32 H_DD = H(P, m);
       u32 H1_DD = H1(P, m);
       return (H_DD == H1_DD) ? H_DD : H1_DD;
    }

    and

    D is defined something like:
    D(P) {
       if(HD(P,P)) {
         while(1) ;
       }
    }

    Which still gives the wrong answer.


    You seem to be forgetting what a Halt Decider needs to be.

    At the Turing machine level any D can make it impossible for a
    particular H to be unable to correctly report on the behavior of the
    directly executed D(D). Because D is a fixed constant finite string it
    cannot dynamically reconfigure itself to fool a different H.



    So, you don't understand the problem.

    D doesn't even exist as an input until you define the H

    So you want a TM to decide halting for an imaginary input?
    That is not the way that computation actually works.

    In computability theory and computational complexity theory, a decision
    problem is a computational problem that can be posed as a yes–no
    question of the input values.
    https://en.wikipedia.org/wiki/Decision_problem

    TM's do not take ideas held within the mind as their inputs, they only
    take fixed constant finite strings as inputs.

    --
    Copyright 2023 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 olcott@21:1/5 to Richard Damon on Mon Jul 3 10:44:17 2023
    XPost: comp.theory, sci.logic

    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 10:42 AM, olcott wrote:
    On 7/3/2023 8:13 AM, Richard Damon wrote:
    On 7/2/23 11:10 PM, olcott wrote:

    Only when I show you are wrong. Actually try to answer my objections


    What about a three valued decider?
    0=undecidable
    1=halting
    2=not halting


    Doesn't meet the definition of a Halt Decider.


    Because these are semantic properties based on the behavior of
    the input it does refute Rice.

    After all, ALL inputs to H represent a computation that either Halts or
    Not, so "Undecidable" isn't a correct answer for the behavior of that machine.

    So, all you are doing is showing that you don't understand that actual problem you claim to be solving.

    --
    Copyright 2023 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 olcott@21:1/5 to Richard Damon on Mon Jul 3 10:56:08 2023
    XPost: comp.theory, sci.logic

    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 10:45 AM, olcott wrote:
    On 7/3/2023 9:24 AM, Richard Damon wrote:
    On 7/3/23 9:47 AM, olcott wrote:
    On 7/3/2023 8:14 AM, Richard Damon wrote:
    On 7/2/23 10:48 PM, olcott wrote:
    On 7/2/2023 9:41 PM, Richard Damon wrote:
    On 7/2/23 10:01 PM, olcott wrote:
    On 7/2/2023 8:40 PM, Richard Damon wrote:
    On 7/2/23 8:45 PM, olcott wrote:
    A single H can consistently correctly determine whether or not >>>>>>>>>> its input
    is pathological relative to itself. When H(D,D) is invoked in >>>>>>>>>> decidability decider mode determines that D is pathological >>>>>>>>>> relative to
    itself this enables a batch file to invoke H1(D,D) to get the >>>>>>>>>> actual
    behavior of the directly executed D(D). H1 is identical to H >>>>>>>>>> except for
    the pathological relationship to H.



    And does an input D that uses this FULL algorithm give your
    algorithm problems?

    Since H(D,D) will (apparently) determine that the input is
    pathological, and thus defer to H1(D,D), then when we actually >>>>>>>>> run D, appearently it will get that same answer from H1 and do >>>>>>>>> the opposite of it, and thus H1 will be wrong.

    Remember, the "Pathological" program is built on a copy of the >>>>>>>>> ACTUAL program that you ask to decide on it, including ALL of >>>>>>>>> its "tricks", including things like this "batch processing". >>>>>>>>>
    You seem to be assuming that there is some "Operationg System" >>>>>>>>> outside the Decider - Input structure, but there isn't, at
    least not one that can affect the answer of the problem.

    I spent 12 hours a day for the last 10 days getting the copy the >>>>>>>> input
    working. When H(D,D) (in decidability decider mode) detects that >>>>>>>> its
    input is in the well defined set of pathological inputs it
    returns 0
    indicating that its input is undecidable. The batch file that
    invoked H
    then knows to invoke H1(D,D) to correctly report that D(D) halts. >>>>>>>>
    This solution does seem to work correctly on every conventional >>>>>>>> proof in
    every textbook.


    So, did you make your "conventional proof" template actually use >>>>>>> a copy of your ACTUAL decider (which seems to be your "batch
    file" not the C funciton H), or are you just admitting that you
    wasted 120 hours looking at the wrong thing because you have made >>>>>>> yourself intentionally ignorant of the subject so you don't
    understand what you are trying to do.

    New_D copies its input and simulates its input with its input.
    It never sees New_H.


    Why not? Since New_H is the thing that is considered the "Correct
    Halt Decider", New_D needs to be built on it.


    New_H is embedded within New_D (as its middle states) just the
    way it is supposed to be. The question is: Does New_H(New_H) halt?

    The only difference at the source code level is:
    (a) New_H copies its input, thus takes one param.
    (b) New_H has an infinite loop at its accept state.

    So, how is New_H a halt decider then?

    typo
    The only difference at the source code level is:
    (a) New_D copies its input, thus takes one param.
    (b) New_D has an infinite loop at its accept state.
    Other than that (at the source-code level) New_D is exactly New_H



    But New_D needs to call New_H,

    Not in the Peter Linz proof:
    https://www.liarparadox.org/Linz_Proof.pdf

    In the Linz proof a copy of H is directly embedded
    within Ĥ at this state: Ĥq0 Wm Wm
    The original H remains unchanged.

    The halting problem is about undecidable inputs, it is not about
    inserting bugs into a halt decider to make it cease to function.


    --
    Copyright 2023 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 Mon Jul 3 11:58:58 2023
    XPost: comp.theory, sci.logic

    On 7/3/23 11:41 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 11:10 AM, olcott wrote:
    At the Turing machine level any D can make it impossible for a
    particular H to be unable to correctly report on the behavior of the
    directly executed D(D). Because D is a fixed constant finite string it
    cannot dynamically reconfigure itself to fool a different H.



    So, you don't understand the problem.

    D doesn't even exist as an input until you define the H

    So you want a TM to decide halting for an imaginary input?
    That is not the way that computation actually works.

    Nope, it must decide for ALL inputs, even those that haven't been
    'created' yet.

    Once you create H, you can create D. That will be one of the infinite
    set of possible inputs that H was designed to decide on.

    When we RUN H, the input exists. Until you decide on what H will be, we
    don't know which of all the possible inputs D will be.


    In computability theory and computational complexity theory, a decision problem is a computational problem that can be posed as a yes–no
    question of the input values.
    https://en.wikipedia.org/wiki/Decision_problem

    Right, and it must accept ALL inputs, it can take the input based on
    itself, which we don't know which one it will be until we define the
    decider.


    TM's do not take ideas held within the mind as their inputs, they only
    take fixed constant finite strings as inputs.


    Right, but since it takes ALL inputs, it can take an input based on
    itself, which of course we can't figure out which of the infinte number
    of possible inputs it will be until we define the decider.

    You keep on missing that 'D' isn't a fixed input that breaks ALL
    deciders, but an input that is only shown to break a particular decider
    (but any of them). The proof define a TEMPLATE to construct this input
    from the decider, and thus shows that for ANY decider we can make such
    an input that it can't decide.

    Thus, changing H means you need to look at the D built on it, which will
    be a different input then the 'D' built on any other decider.

    This is why Linz used the ^ notation, given any decider H, you can make
    the input H^ that shows it is wrong. The ^ marking a transformation. If
    the decider is H1, then the input is H1^. This allows for the discussion
    of "all deciders".

    The H/P and H/D notations have built in that we are talking about a
    particular H for the whole discussion, or we need to go to Hn / Pn type notations.

    Your omitting of distinct names for you various versions of H is just
    your attempt to be intentionally deceptive, as shown by your claim that
    D is a 'fixed string', for all H, when it is only a fixed string for a
    given H. Each Hi gets its own fixed string Di.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to Richard Damon on Mon Jul 3 11:58:52 2023
    XPost: comp.theory, sci.logic

    On 7/3/23 11:35 AM, Richard Damon wrote:
    On 7/3/23 10:42 AM, olcott wrote:
    On 7/3/2023 8:13 AM, Richard Damon wrote:
    On 7/2/23 11:10 PM, olcott wrote:

    Only when I show you are wrong. Actually try to answer my objections


    What about a three valued decider?
    0=undecidable
    1=halting
    2=not halting


    Doesn't meet the definition of a Halt Decider.

    After all, ALL inputs to H represent a computation that either Halts or
    Not, so "Undecidable" isn't a correct answer for the behavior of that machine.

    So, all you are doing is showing that you don't understand that actual problem you claim to be solving.

    Or, to put it another way, to add the "Undecidable" output state means
    that you are admitting that Halting IS undecidable, and thus the Halting Theorem, which states that, is correct and you are not trying to refute it.

    The second part of the problem then is that for any H that gives an
    answer to H(D,D) the "undecidable" answer, or which is provably
    non-answering, will be incorrect, as that input IS decidably Halting or Non-Halting (Depending on the behavior assigned in D to the undecidable
    answwer as "contrary", but both Halting and Looping Forever are contrary
    to not being decidable).

    The interesting thing about halting is the "undecidable" case can NEVER actually be proven, as that leads to a contradiction, as an undecidable
    machine MUST be non-halting, as all Halting Machines can be proven in
    finite time to Halt, so the only way to actually be undecidable is to be non-halting, so proving undecidable actually proves that it would be
    decidable as non-halting.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Mon Jul 3 12:01:40 2023
    XPost: comp.theory, sci.logic

    On 7/3/23 11:56 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 10:45 AM, olcott wrote:
    On 7/3/2023 9:24 AM, Richard Damon wrote:
    On 7/3/23 9:47 AM, olcott wrote:
    On 7/3/2023 8:14 AM, Richard Damon wrote:
    On 7/2/23 10:48 PM, olcott wrote:
    On 7/2/2023 9:41 PM, Richard Damon wrote:
    On 7/2/23 10:01 PM, olcott wrote:
    On 7/2/2023 8:40 PM, Richard Damon wrote:
    On 7/2/23 8:45 PM, olcott wrote:
    A single H can consistently correctly determine whether or >>>>>>>>>>> not its input
    is pathological relative to itself. When H(D,D) is invoked in >>>>>>>>>>> decidability decider mode determines that D is pathological >>>>>>>>>>> relative to
    itself this enables a batch file to invoke H1(D,D) to get the >>>>>>>>>>> actual
    behavior of the directly executed D(D). H1 is identical to H >>>>>>>>>>> except for
    the pathological relationship to H.



    And does an input D that uses this FULL algorithm give your >>>>>>>>>> algorithm problems?

    Since H(D,D) will (apparently) determine that the input is >>>>>>>>>> pathological, and thus defer to H1(D,D), then when we actually >>>>>>>>>> run D, appearently it will get that same answer from H1 and do >>>>>>>>>> the opposite of it, and thus H1 will be wrong.

    Remember, the "Pathological" program is built on a copy of the >>>>>>>>>> ACTUAL program that you ask to decide on it, including ALL of >>>>>>>>>> its "tricks", including things like this "batch processing". >>>>>>>>>>
    You seem to be assuming that there is some "Operationg System" >>>>>>>>>> outside the Decider - Input structure, but there isn't, at >>>>>>>>>> least not one that can affect the answer of the problem.

    I spent 12 hours a day for the last 10 days getting the copy >>>>>>>>> the input
    working. When H(D,D) (in decidability decider mode) detects
    that its
    input is in the well defined set of pathological inputs it
    returns 0
    indicating that its input is undecidable. The batch file that >>>>>>>>> invoked H
    then knows to invoke H1(D,D) to correctly report that D(D) halts. >>>>>>>>>
    This solution does seem to work correctly on every conventional >>>>>>>>> proof in
    every textbook.


    So, did you make your "conventional proof" template actually use >>>>>>>> a copy of your ACTUAL decider (which seems to be your "batch
    file" not the C funciton H), or are you just admitting that you >>>>>>>> wasted 120 hours looking at the wrong thing because you have
    made yourself intentionally ignorant of the subject so you don't >>>>>>>> understand what you are trying to do.

    New_D copies its input and simulates its input with its input.
    It never sees New_H.


    Why not? Since New_H is the thing that is considered the "Correct
    Halt Decider", New_D needs to be built on it.


    New_H is embedded within New_D (as its middle states) just the
    way it is supposed to be. The question is: Does New_H(New_H) halt?

    The only difference at the source code level is:
    (a) New_H copies its input, thus takes one param.
    (b) New_H has an infinite loop at its accept state.

    So, how is New_H a halt decider then?

    typo
    The only difference at the source code level is:
    (a) New_D copies its input, thus takes one param.
    (b) New_D has an infinite loop at its accept state.
    Other than that (at the source-code level) New_D is exactly New_H



    But New_D needs to call New_H,

    Not in the Peter Linz proof:
    https://www.liarparadox.org/Linz_Proof.pdf

    In the Linz proof a copy of H is directly embedded
    within Ĥ at this state: Ĥq0 Wm Wm
    The original H remains unchanged.

    The halting problem is about undecidable inputs, it is not about
    inserting bugs into a halt decider to make it cease to function.



    Right, and in Linz, H is the decider that is claimed to give the right
    answer.

    That isn't 'H' in your system, but the script that decides whether to
    use H or H1.

    Your error is in calling the wrong thing 'H'

    You are just showing you are lying by using the wrong name for things.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Richard Damon on Mon Jul 3 11:11:49 2023
    XPost: comp.theory, sci.logic

    On 7/3/2023 11:01 AM, Richard Damon wrote:
    On 7/3/23 11:56 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 10:45 AM, olcott wrote:
    On 7/3/2023 9:24 AM, Richard Damon wrote:
    On 7/3/23 9:47 AM, olcott wrote:
    On 7/3/2023 8:14 AM, Richard Damon wrote:
    On 7/2/23 10:48 PM, olcott wrote:
    On 7/2/2023 9:41 PM, Richard Damon wrote:
    On 7/2/23 10:01 PM, olcott wrote:
    On 7/2/2023 8:40 PM, Richard Damon wrote:
    On 7/2/23 8:45 PM, olcott wrote:
    A single H can consistently correctly determine whether or >>>>>>>>>>>> not its input
    is pathological relative to itself. When H(D,D) is invoked in >>>>>>>>>>>> decidability decider mode determines that D is pathological >>>>>>>>>>>> relative to
    itself this enables a batch file to invoke H1(D,D) to get >>>>>>>>>>>> the actual
    behavior of the directly executed D(D). H1 is identical to H >>>>>>>>>>>> except for
    the pathological relationship to H.



    And does an input D that uses this FULL algorithm give your >>>>>>>>>>> algorithm problems?

    Since H(D,D) will (apparently) determine that the input is >>>>>>>>>>> pathological, and thus defer to H1(D,D), then when we
    actually run D, appearently it will get that same answer from >>>>>>>>>>> H1 and do the opposite of it, and thus H1 will be wrong. >>>>>>>>>>>
    Remember, the "Pathological" program is built on a copy of >>>>>>>>>>> the ACTUAL program that you ask to decide on it, including >>>>>>>>>>> ALL of its "tricks", including things like this "batch
    processing".

    You seem to be assuming that there is some "Operationg
    System" outside the Decider - Input structure, but there >>>>>>>>>>> isn't, at least not one that can affect the answer of the >>>>>>>>>>> problem.

    I spent 12 hours a day for the last 10 days getting the copy >>>>>>>>>> the input
    working. When H(D,D) (in decidability decider mode) detects >>>>>>>>>> that its
    input is in the well defined set of pathological inputs it >>>>>>>>>> returns 0
    indicating that its input is undecidable. The batch file that >>>>>>>>>> invoked H
    then knows to invoke H1(D,D) to correctly report that D(D) halts. >>>>>>>>>>
    This solution does seem to work correctly on every
    conventional proof in
    every textbook.


    So, did you make your "conventional proof" template actually >>>>>>>>> use a copy of your ACTUAL decider (which seems to be your
    "batch file" not the C funciton H), or are you just admitting >>>>>>>>> that you wasted 120 hours looking at the wrong thing because >>>>>>>>> you have made yourself intentionally ignorant of the subject so >>>>>>>>> you don't understand what you are trying to do.

    New_D copies its input and simulates its input with its input. >>>>>>>> It never sees New_H.


    Why not? Since New_H is the thing that is considered the "Correct >>>>>>> Halt Decider", New_D needs to be built on it.


    New_H is embedded within New_D (as its middle states) just the
    way it is supposed to be. The question is: Does New_H(New_H) halt? >>>>>>
    The only difference at the source code level is:
    (a) New_H copies its input, thus takes one param.
    (b) New_H has an infinite loop at its accept state.

    So, how is New_H a halt decider then?

    typo
    The only difference at the source code level is:
    (a) New_D copies its input, thus takes one param.
    (b) New_D has an infinite loop at its accept state.
    Other than that (at the source-code level) New_D is exactly New_H



    But New_D needs to call New_H,

    Not in the Peter Linz proof:
    https://www.liarparadox.org/Linz_Proof.pdf

    In the Linz proof a copy of H is directly embedded
    within Ĥ at this state: Ĥq0 Wm Wm
    The original H remains unchanged.

    The halting problem is about undecidable inputs, it is not about
    inserting bugs into a halt decider to make it cease to function.



    Right, and in Linz, H is the decider that is claimed to give the right answer.

    That isn't 'H' in your system, but the script that decides whether to
    use H or H1.

    Your error is in calling the wrong thing 'H'

    You are just showing you are lying by using the wrong name for things.

    You are using double-talk in a lame attempt to show that
    Linz H cannot correctly determine the halt status of Linz Ĥ.

    --
    Copyright 2023 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 olcott@21:1/5 to Richard Damon on Mon Jul 3 11:09:03 2023
    XPost: comp.theory, sci.logic

    On 7/3/2023 10:58 AM, Richard Damon wrote:
    On 7/3/23 11:41 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 11:10 AM, olcott wrote:
    At the Turing machine level any D can make it impossible for a
    particular H to be unable to correctly report on the behavior of the
    directly executed D(D). Because D is a fixed constant finite string it >>>> cannot dynamically reconfigure itself to fool a different H.



    So, you don't understand the problem.

    D doesn't even exist as an input until you define the H

    So you want a TM to decide halting for an imaginary input?
    That is not the way that computation actually works.

    Nope, it must decide for ALL inputs, even those that haven't been
    'created' yet.

    Once you create H, you can create D. That will be one of the infinite
    set of possible inputs that H was designed to decide on.

    When we RUN H, the input exists. Until you decide on what H will be, we
    don't know which of all the possible inputs D will be.


    In computability theory and computational complexity theory, a decision
    problem is a computational problem that can be posed as a yes–no
    question of the input values.
    https://en.wikipedia.org/wiki/Decision_problem

    Right, and it must accept ALL inputs, it can take the input based on
    itself, which we don't know which one it will be until we define the
    decider.


    TM's do not take ideas held within the mind as their inputs, they only
    take fixed constant finite strings as inputs.


    Right, but since it takes ALL inputs, it can take an input based on
    itself,

    None-the-less you continue to assert that it must take ideas as inputs.
    It just doesn't work that way.

    --
    Copyright 2023 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 olcott@21:1/5 to Richard Damon on Mon Jul 3 11:05:46 2023
    XPost: comp.theory, sci.logic

    On 7/3/2023 10:58 AM, Richard Damon wrote:
    On 7/3/23 11:44 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 10:42 AM, olcott wrote:
    On 7/3/2023 8:13 AM, Richard Damon wrote:
    On 7/2/23 11:10 PM, olcott wrote:

    Only when I show you are wrong. Actually try to answer my objections


    What about a three valued decider?
    0=undecidable
    1=halting
    2=not halting


    Doesn't meet the definition of a Halt Decider.


    Because these are semantic properties based on the behavior of
    the input it does refute Rice.

    Nope. Rice's theorem doesn't allow for an 'undecidable' output state
    either.

    Either the input is or is not something that is in the set defined by
    the function/language defined.

    Undecidable is just admitting that Rice is true.


    Undecidable <is> a semantic property.


    After all, ALL inputs to H represent a computation that either Halts
    or Not, so "Undecidable" isn't a correct answer for the behavior of
    that machine.

    So, all you are doing is showing that you don't understand that
    actual problem you claim to be solving.



    --
    Copyright 2023 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 Mon Jul 3 12:26:24 2023
    XPost: comp.theory, sci.logic

    On 7/3/23 12:11 PM, olcott wrote:
    On 7/3/2023 11:01 AM, Richard Damon wrote:
    On 7/3/23 11:56 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 10:45 AM, olcott wrote:
    On 7/3/2023 9:24 AM, Richard Damon wrote:
    On 7/3/23 9:47 AM, olcott wrote:
    On 7/3/2023 8:14 AM, Richard Damon wrote:
    On 7/2/23 10:48 PM, olcott wrote:
    On 7/2/2023 9:41 PM, Richard Damon wrote:
    On 7/2/23 10:01 PM, olcott wrote:
    On 7/2/2023 8:40 PM, Richard Damon wrote:
    On 7/2/23 8:45 PM, olcott wrote:
    A single H can consistently correctly determine whether or >>>>>>>>>>>>> not its input
    is pathological relative to itself. When H(D,D) is invoked in >>>>>>>>>>>>> decidability decider mode determines that D is pathological >>>>>>>>>>>>> relative to
    itself this enables a batch file to invoke H1(D,D) to get >>>>>>>>>>>>> the actual
    behavior of the directly executed D(D). H1 is identical to >>>>>>>>>>>>> H except for
    the pathological relationship to H.



    And does an input D that uses this FULL algorithm give your >>>>>>>>>>>> algorithm problems?

    Since H(D,D) will (apparently) determine that the input is >>>>>>>>>>>> pathological, and thus defer to H1(D,D), then when we
    actually run D, appearently it will get that same answer >>>>>>>>>>>> from H1 and do the opposite of it, and thus H1 will be wrong. >>>>>>>>>>>>
    Remember, the "Pathological" program is built on a copy of >>>>>>>>>>>> the ACTUAL program that you ask to decide on it, including >>>>>>>>>>>> ALL of its "tricks", including things like this "batch >>>>>>>>>>>> processing".

    You seem to be assuming that there is some "Operationg >>>>>>>>>>>> System" outside the Decider - Input structure, but there >>>>>>>>>>>> isn't, at least not one that can affect the answer of the >>>>>>>>>>>> problem.

    I spent 12 hours a day for the last 10 days getting the copy >>>>>>>>>>> the input
    working. When H(D,D) (in decidability decider mode) detects >>>>>>>>>>> that its
    input is in the well defined set of pathological inputs it >>>>>>>>>>> returns 0
    indicating that its input is undecidable. The batch file that >>>>>>>>>>> invoked H
    then knows to invoke H1(D,D) to correctly report that D(D) >>>>>>>>>>> halts.

    This solution does seem to work correctly on every
    conventional proof in
    every textbook.


    So, did you make your "conventional proof" template actually >>>>>>>>>> use a copy of your ACTUAL decider (which seems to be your
    "batch file" not the C funciton H), or are you just admitting >>>>>>>>>> that you wasted 120 hours looking at the wrong thing because >>>>>>>>>> you have made yourself intentionally ignorant of the subject >>>>>>>>>> so you don't understand what you are trying to do.

    New_D copies its input and simulates its input with its input. >>>>>>>>> It never sees New_H.


    Why not? Since New_H is the thing that is considered the
    "Correct Halt Decider", New_D needs to be built on it.


    New_H is embedded within New_D (as its middle states) just the
    way it is supposed to be. The question is: Does New_H(New_H) halt? >>>>>>>
    The only difference at the source code level is:
    (a) New_H copies its input, thus takes one param.
    (b) New_H has an infinite loop at its accept state.

    So, how is New_H a halt decider then?

    typo
    The only difference at the source code level is:
    (a) New_D copies its input, thus takes one param.
    (b) New_D has an infinite loop at its accept state.
    Other than that (at the source-code level) New_D is exactly New_H



    But New_D needs to call New_H,

    Not in the Peter Linz proof:
    https://www.liarparadox.org/Linz_Proof.pdf

    In the Linz proof a copy of H is directly embedded
    within Ĥ at this state: Ĥq0 Wm Wm
    The original H remains unchanged.

    The halting problem is about undecidable inputs, it is not about
    inserting bugs into a halt decider to make it cease to function.



    Right, and in Linz, H is the decider that is claimed to give the right
    answer.

    That isn't 'H' in your system, but the script that decides whether to
    use H or H1.

    Your error is in calling the wrong thing 'H'

    You are just showing you are lying by using the wrong name for things.

    You are using double-talk in a lame attempt to show that
    Linz H cannot correctly determine the halt status of Linz Ĥ.


    So you agree with the Theorem.

    No 'Linz H' can exist that correctly decides the halt status of Linz Ĥ
    applied to the description of Linz Ĥ.

    That is EXACTLY the consequence of the Halting Theorem.


    Please show an ACTUAL 'Linz H' that correctly gets the results of the
    'Linz Ĥ' built on it. You keep on changing H and trying to use the old Ĥ which just fails to meet the requirement of the proof, likely because
    you just don't understand the theory involved.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Richard Damon on Mon Jul 3 12:57:00 2023
    XPost: comp.theory, sci.logic

    On 7/3/2023 11:26 AM, Richard Damon wrote:
    On 7/3/23 12:11 PM, olcott wrote:
    On 7/3/2023 11:01 AM, Richard Damon wrote:
    On 7/3/23 11:56 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 10:45 AM, olcott wrote:
    On 7/3/2023 9:24 AM, Richard Damon wrote:
    On 7/3/23 9:47 AM, olcott wrote:
    On 7/3/2023 8:14 AM, Richard Damon wrote:
    On 7/2/23 10:48 PM, olcott wrote:
    On 7/2/2023 9:41 PM, Richard Damon wrote:
    On 7/2/23 10:01 PM, olcott wrote:
    On 7/2/2023 8:40 PM, Richard Damon wrote:
    On 7/2/23 8:45 PM, olcott wrote:
    A single H can consistently correctly determine whether or >>>>>>>>>>>>>> not its input
    is pathological relative to itself. When H(D,D) is invoked in >>>>>>>>>>>>>> decidability decider mode determines that D is
    pathological relative to
    itself this enables a batch file to invoke H1(D,D) to get >>>>>>>>>>>>>> the actual
    behavior of the directly executed D(D). H1 is identical to >>>>>>>>>>>>>> H except for
    the pathological relationship to H.



    And does an input D that uses this FULL algorithm give your >>>>>>>>>>>>> algorithm problems?

    Since H(D,D) will (apparently) determine that the input is >>>>>>>>>>>>> pathological, and thus defer to H1(D,D), then when we >>>>>>>>>>>>> actually run D, appearently it will get that same answer >>>>>>>>>>>>> from H1 and do the opposite of it, and thus H1 will be wrong. >>>>>>>>>>>>>
    Remember, the "Pathological" program is built on a copy of >>>>>>>>>>>>> the ACTUAL program that you ask to decide on it, including >>>>>>>>>>>>> ALL of its "tricks", including things like this "batch >>>>>>>>>>>>> processing".

    You seem to be assuming that there is some "Operationg >>>>>>>>>>>>> System" outside the Decider - Input structure, but there >>>>>>>>>>>>> isn't, at least not one that can affect the answer of the >>>>>>>>>>>>> problem.

    I spent 12 hours a day for the last 10 days getting the copy >>>>>>>>>>>> the input
    working. When H(D,D) (in decidability decider mode) detects >>>>>>>>>>>> that its
    input is in the well defined set of pathological inputs it >>>>>>>>>>>> returns 0
    indicating that its input is undecidable. The batch file >>>>>>>>>>>> that invoked H
    then knows to invoke H1(D,D) to correctly report that D(D) >>>>>>>>>>>> halts.

    This solution does seem to work correctly on every
    conventional proof in
    every textbook.


    So, did you make your "conventional proof" template actually >>>>>>>>>>> use a copy of your ACTUAL decider (which seems to be your >>>>>>>>>>> "batch file" not the C funciton H), or are you just admitting >>>>>>>>>>> that you wasted 120 hours looking at the wrong thing because >>>>>>>>>>> you have made yourself intentionally ignorant of the subject >>>>>>>>>>> so you don't understand what you are trying to do.

    New_D copies its input and simulates its input with its input. >>>>>>>>>> It never sees New_H.


    Why not? Since New_H is the thing that is considered the
    "Correct Halt Decider", New_D needs to be built on it.


    New_H is embedded within New_D (as its middle states) just the >>>>>>>> way it is supposed to be. The question is: Does New_H(New_H) halt? >>>>>>>>
    The only difference at the source code level is:
    (a) New_H copies its input, thus takes one param.
    (b) New_H has an infinite loop at its accept state.

    So, how is New_H a halt decider then?

    typo
    The only difference at the source code level is:
    (a) New_D copies its input, thus takes one param.
    (b) New_D has an infinite loop at its accept state.
    Other than that (at the source-code level) New_D is exactly New_H



    But New_D needs to call New_H,

    Not in the Peter Linz proof:
    https://www.liarparadox.org/Linz_Proof.pdf

    In the Linz proof a copy of H is directly embedded
    within Ĥ at this state: Ĥq0 Wm Wm
    The original H remains unchanged.

    The halting problem is about undecidable inputs, it is not about
    inserting bugs into a halt decider to make it cease to function.



    Right, and in Linz, H is the decider that is claimed to give the
    right answer.

    That isn't 'H' in your system, but the script that decides whether to
    use H or H1.

    Your error is in calling the wrong thing 'H'

    You are just showing you are lying by using the wrong name for things.

    You are using double-talk in a lame attempt to show that
    Linz H cannot correctly determine the halt status of Linz Ĥ.


    So you agree with the Theorem.

    No 'Linz H' can exist that correctly decides the halt status of Linz Ĥ applied to the description of Linz Ĥ.

    That is EXACTLY the consequence of the Halting Theorem.


    Please show an ACTUAL 'Linz H' that correctly gets the results of the
    'Linz Ĥ' built on it. You keep on changing H and trying to use the old Ĥ which just fails to meet the requirement of the proof, likely because
    you just don't understand the theory involved.

    It took me two years to figure out a clean way to copy the input to
    Linz_H_Hat and not have the system crash. Relative to Linz_H_Hat
    Linz_H is H1. Now Linz_H_Hat only contradicts itself.

    --
    Copyright 2023 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 olcott@21:1/5 to Richard Damon on Mon Jul 3 13:00:06 2023
    XPost: comp.theory, sci.logic

    On 7/3/2023 11:26 AM, Richard Damon wrote:
    On 7/3/23 12:09 PM, olcott wrote:
    On 7/3/2023 10:58 AM, Richard Damon wrote:
    On 7/3/23 11:41 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 11:10 AM, olcott wrote:
    At the Turing machine level any D can make it impossible for a
    particular H to be unable to correctly report on the behavior of the >>>>>> directly executed D(D). Because D is a fixed constant finite
    string it
    cannot dynamically reconfigure itself to fool a different H.



    So, you don't understand the problem.

    D doesn't even exist as an input until you define the H

    So you want a TM to decide halting for an imaginary input?
    That is not the way that computation actually works.

    Nope, it must decide for ALL inputs, even those that haven't been
    'created' yet.

    Once you create H, you can create D. That will be one of the infinite
    set of possible inputs that H was designed to decide on.

    When we RUN H, the input exists. Until you decide on what H will be,
    we don't know which of all the possible inputs D will be.


    In computability theory and computational complexity theory, a decision >>>> problem is a computational problem that can be posed as a yes–no
    question of the input values.
    https://en.wikipedia.org/wiki/Decision_problem

    Right, and it must accept ALL inputs, it can take the input based on
    itself, which we don't know which one it will be until we define the
    decider.


    TM's do not take ideas held within the mind as their inputs, they only >>>> take fixed constant finite strings as inputs.


    Right, but since it takes ALL inputs, it can take an input based on
    itself,

    None-the-less you continue to assert that it must take ideas as inputs.
    It just doesn't work that way.


    Nope, Where did I say THAT.

    On 7/3/2023 10:58 AM, Richard Damon wrote:
    Nope, it must decide for ALL inputs, even those that haven't been
    'created' yet.




    --
    Copyright 2023 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 olcott@21:1/5 to Richard Damon on Mon Jul 3 13:03:30 2023
    XPost: comp.theory, sci.logic

    On 7/3/2023 11:26 AM, Richard Damon wrote:
    On 7/3/23 12:05 PM, olcott wrote:
    On 7/3/2023 10:58 AM, Richard Damon wrote:
    On 7/3/23 11:44 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 10:42 AM, olcott wrote:
    On 7/3/2023 8:13 AM, Richard Damon wrote:
    On 7/2/23 11:10 PM, olcott wrote:

    Only when I show you are wrong. Actually try to answer my objections >>>>>>

    What about a three valued decider?
    0=undecidable
    1=halting
    2=not halting


    Doesn't meet the definition of a Halt Decider.


    Because these are semantic properties based on the behavior of
    the input it does refute Rice.

    Nope. Rice's theorem doesn't allow for an 'undecidable' output state
    either.

    Either the input is or is not something that is in the set defined by
    the function/language defined.

    Undecidable is just admitting that Rice is true.


    Undecidable <is> a semantic property.

    Source of that Claim?

    And you aren't saying the Undecidable <IS> a semantic property, but is
    an answer for if an input <HAS> some specific semantic property.

    In computability theory, Rice's theorem states that all non-trivial
    semantic properties of programs are undecidable. A semantic property is
    one about the program's behavior
    https://en.wikipedia.org/wiki/Rice%27s_theorem

    Undecidable <is> a semantic property of the finite string pair: {H,D}.

    --
    Copyright 2023 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 Mon Jul 3 14:25:16 2023
    XPost: comp.theory, sci.logic

    On 7/3/23 1:57 PM, olcott wrote:
    On 7/3/2023 11:26 AM, Richard Damon wrote:
    On 7/3/23 12:11 PM, olcott wrote:
    On 7/3/2023 11:01 AM, Richard Damon wrote:
    On 7/3/23 11:56 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 10:45 AM, olcott wrote:
    On 7/3/2023 9:24 AM, Richard Damon wrote:
    On 7/3/23 9:47 AM, olcott wrote:
    On 7/3/2023 8:14 AM, Richard Damon wrote:
    On 7/2/23 10:48 PM, olcott wrote:
    On 7/2/2023 9:41 PM, Richard Damon wrote:
    On 7/2/23 10:01 PM, olcott wrote:
    On 7/2/2023 8:40 PM, Richard Damon wrote:
    On 7/2/23 8:45 PM, olcott wrote:
    A single H can consistently correctly determine whether >>>>>>>>>>>>>>> or not its input
    is pathological relative to itself. When H(D,D) is >>>>>>>>>>>>>>> invoked in
    decidability decider mode determines that D is
    pathological relative to
    itself this enables a batch file to invoke H1(D,D) to get >>>>>>>>>>>>>>> the actual
    behavior of the directly executed D(D). H1 is identical >>>>>>>>>>>>>>> to H except for
    the pathological relationship to H.



    And does an input D that uses this FULL algorithm give >>>>>>>>>>>>>> your algorithm problems?

    Since H(D,D) will (apparently) determine that the input is >>>>>>>>>>>>>> pathological, and thus defer to H1(D,D), then when we >>>>>>>>>>>>>> actually run D, appearently it will get that same answer >>>>>>>>>>>>>> from H1 and do the opposite of it, and thus H1 will be wrong. >>>>>>>>>>>>>>
    Remember, the "Pathological" program is built on a copy of >>>>>>>>>>>>>> the ACTUAL program that you ask to decide on it, including >>>>>>>>>>>>>> ALL of its "tricks", including things like this "batch >>>>>>>>>>>>>> processing".

    You seem to be assuming that there is some "Operationg >>>>>>>>>>>>>> System" outside the Decider - Input structure, but there >>>>>>>>>>>>>> isn't, at least not one that can affect the answer of the >>>>>>>>>>>>>> problem.

    I spent 12 hours a day for the last 10 days getting the >>>>>>>>>>>>> copy the input
    working. When H(D,D) (in decidability decider mode) detects >>>>>>>>>>>>> that its
    input is in the well defined set of pathological inputs it >>>>>>>>>>>>> returns 0
    indicating that its input is undecidable. The batch file >>>>>>>>>>>>> that invoked H
    then knows to invoke H1(D,D) to correctly report that D(D) >>>>>>>>>>>>> halts.

    This solution does seem to work correctly on every
    conventional proof in
    every textbook.


    So, did you make your "conventional proof" template actually >>>>>>>>>>>> use a copy of your ACTUAL decider (which seems to be your >>>>>>>>>>>> "batch file" not the C funciton H), or are you just
    admitting that you wasted 120 hours looking at the wrong >>>>>>>>>>>> thing because you have made yourself intentionally ignorant >>>>>>>>>>>> of the subject so you don't understand what you are trying >>>>>>>>>>>> to do.

    New_D copies its input and simulates its input with its input. >>>>>>>>>>> It never sees New_H.


    Why not? Since New_H is the thing that is considered the
    "Correct Halt Decider", New_D needs to be built on it.


    New_H is embedded within New_D (as its middle states) just the >>>>>>>>> way it is supposed to be. The question is: Does New_H(New_H) halt? >>>>>>>>>
    The only difference at the source code level is:
    (a) New_H copies its input, thus takes one param.
    (b) New_H has an infinite loop at its accept state.

    So, how is New_H a halt decider then?

    typo
    The only difference at the source code level is:
    (a) New_D copies its input, thus takes one param.
    (b) New_D has an infinite loop at its accept state.
    Other than that (at the source-code level) New_D is exactly New_H >>>>>>>


    But New_D needs to call New_H,

    Not in the Peter Linz proof:
    https://www.liarparadox.org/Linz_Proof.pdf

    In the Linz proof a copy of H is directly embedded
    within Ĥ at this state: Ĥq0 Wm Wm
    The original H remains unchanged.

    The halting problem is about undecidable inputs, it is not about
    inserting bugs into a halt decider to make it cease to function.



    Right, and in Linz, H is the decider that is claimed to give the
    right answer.

    That isn't 'H' in your system, but the script that decides whether
    to use H or H1.

    Your error is in calling the wrong thing 'H'

    You are just showing you are lying by using the wrong name for things.

    You are using double-talk in a lame attempt to show that
    Linz H cannot correctly determine the halt status of Linz Ĥ.


    So you agree with the Theorem.

    No 'Linz H' can exist that correctly decides the halt status of Linz Ĥ
    applied to the description of Linz Ĥ.

    That is EXACTLY the consequence of the Halting Theorem.


    Please show an ACTUAL 'Linz H' that correctly gets the results of the
    'Linz Ĥ' built on it. You keep on changing H and trying to use the old
    Ĥ which just fails to meet the requirement of the proof, likely
    because you just don't understand the theory involved.

    It took me two years to figure out a clean way to copy the input to Linz_H_Hat and not have the system crash. Relative to Linz_H_Hat
    Linz_H is H1. Now Linz_H_Hat only contradicts itself.


    So, you are admitting that you actually can't do what is required?

    Copying the input should be trivial, as the input should be a
    representation that packages a full program in its own virtual
    environment, so a simple bit by bit copy to empty ram will work. Your
    problem is that you don't put the input into its own virtual address
    space, so you have pathological interactions.

    Linz_H_Hat must be built on the exact code base that is deciding on it,
    in this case H, since you just said it isn't, your proof is invalid.

    Note, Linz_H_Hat CAN'T "Contradict" itself, as doesn't generate any
    truth values, only behavior. You are just showing that you don't
    understand the basics of the requirements, and seem to think that
    "close" is good enough for proofs.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Richard Damon on Mon Jul 3 13:48:07 2023
    XPost: comp.theory, sci.logic

    On 7/3/2023 1:25 PM, Richard Damon wrote:
    On 7/3/23 1:57 PM, olcott wrote:
    On 7/3/2023 11:26 AM, Richard Damon wrote:
    On 7/3/23 12:11 PM, olcott wrote:
    On 7/3/2023 11:01 AM, Richard Damon wrote:
    On 7/3/23 11:56 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 10:45 AM, olcott wrote:
    On 7/3/2023 9:24 AM, Richard Damon wrote:
    On 7/3/23 9:47 AM, olcott wrote:
    On 7/3/2023 8:14 AM, Richard Damon wrote:
    On 7/2/23 10:48 PM, olcott wrote:
    On 7/2/2023 9:41 PM, Richard Damon wrote:
    On 7/2/23 10:01 PM, olcott wrote:
    On 7/2/2023 8:40 PM, Richard Damon wrote:
    On 7/2/23 8:45 PM, olcott wrote:
    A single H can consistently correctly determine whether >>>>>>>>>>>>>>>> or not its input
    is pathological relative to itself. When H(D,D) is >>>>>>>>>>>>>>>> invoked in
    decidability decider mode determines that D is >>>>>>>>>>>>>>>> pathological relative to
    itself this enables a batch file to invoke H1(D,D) to >>>>>>>>>>>>>>>> get the actual
    behavior of the directly executed D(D). H1 is identical >>>>>>>>>>>>>>>> to H except for
    the pathological relationship to H.



    And does an input D that uses this FULL algorithm give >>>>>>>>>>>>>>> your algorithm problems?

    Since H(D,D) will (apparently) determine that the input >>>>>>>>>>>>>>> is pathological, and thus defer to H1(D,D), then when we >>>>>>>>>>>>>>> actually run D, appearently it will get that same answer >>>>>>>>>>>>>>> from H1 and do the opposite of it, and thus H1 will be >>>>>>>>>>>>>>> wrong.

    Remember, the "Pathological" program is built on a copy >>>>>>>>>>>>>>> of the ACTUAL program that you ask to decide on it, >>>>>>>>>>>>>>> including ALL of its "tricks", including things like this >>>>>>>>>>>>>>> "batch processing".

    You seem to be assuming that there is some "Operationg >>>>>>>>>>>>>>> System" outside the Decider - Input structure, but there >>>>>>>>>>>>>>> isn't, at least not one that can affect the answer of the >>>>>>>>>>>>>>> problem.

    I spent 12 hours a day for the last 10 days getting the >>>>>>>>>>>>>> copy the input
    working. When H(D,D) (in decidability decider mode) >>>>>>>>>>>>>> detects that its
    input is in the well defined set of pathological inputs it >>>>>>>>>>>>>> returns 0
    indicating that its input is undecidable. The batch file >>>>>>>>>>>>>> that invoked H
    then knows to invoke H1(D,D) to correctly report that D(D) >>>>>>>>>>>>>> halts.

    This solution does seem to work correctly on every >>>>>>>>>>>>>> conventional proof in
    every textbook.


    So, did you make your "conventional proof" template
    actually use a copy of your ACTUAL decider (which seems to >>>>>>>>>>>>> be your "batch file" not the C funciton H), or are you just >>>>>>>>>>>>> admitting that you wasted 120 hours looking at the wrong >>>>>>>>>>>>> thing because you have made yourself intentionally ignorant >>>>>>>>>>>>> of the subject so you don't understand what you are trying >>>>>>>>>>>>> to do.

    New_D copies its input and simulates its input with its input. >>>>>>>>>>>> It never sees New_H.


    Why not? Since New_H is the thing that is considered the >>>>>>>>>>> "Correct Halt Decider", New_D needs to be built on it.


    New_H is embedded within New_D (as its middle states) just the >>>>>>>>>> way it is supposed to be. The question is: Does New_H(New_H) >>>>>>>>>> halt?

    The only difference at the source code level is:
    (a) New_H copies its input, thus takes one param.
    (b) New_H has an infinite loop at its accept state.

    So, how is New_H a halt decider then?

    typo
    The only difference at the source code level is:
    (a) New_D copies its input, thus takes one param.
    (b) New_D has an infinite loop at its accept state.
    Other than that (at the source-code level) New_D is exactly New_H >>>>>>>>


    But New_D needs to call New_H,

    Not in the Peter Linz proof:
    https://www.liarparadox.org/Linz_Proof.pdf

    In the Linz proof a copy of H is directly embedded
    within Ĥ at this state: Ĥq0 Wm Wm
    The original H remains unchanged.

    The halting problem is about undecidable inputs, it is not about
    inserting bugs into a halt decider to make it cease to function.



    Right, and in Linz, H is the decider that is claimed to give the
    right answer.

    That isn't 'H' in your system, but the script that decides whether
    to use H or H1.

    Your error is in calling the wrong thing 'H'

    You are just showing you are lying by using the wrong name for things. >>>>
    You are using double-talk in a lame attempt to show that
    Linz H cannot correctly determine the halt status of Linz Ĥ.


    So you agree with the Theorem.

    No 'Linz H' can exist that correctly decides the halt status of Linz
    Ĥ applied to the description of Linz Ĥ.

    That is EXACTLY the consequence of the Halting Theorem.


    Please show an ACTUAL 'Linz H' that correctly gets the results of the
    'Linz Ĥ' built on it. You keep on changing H and trying to use the
    old Ĥ which just fails to meet the requirement of the proof, likely
    because you just don't understand the theory involved.

    It took me two years to figure out a clean way to copy the input to
    Linz_H_Hat and not have the system crash. Relative to Linz_H_Hat
    Linz_H is H1. Now Linz_H_Hat only contradicts itself.


    So, you are admitting that you actually can't do what is required?

    Copying the input should be trivial,

    The relative addressing of the x86 language causes all function
    calls to call the wrong address.

    as the input should be a
    representation that packages a full program in its own virtual
    environment, so a simple bit by bit copy to empty ram will work. Your
    problem is that you don't put the input into its own virtual address
    space, so you have pathological interactions.

    Linz_H_Hat must be built on the exact code base that is deciding on it,
    in this case H, since you just said it isn't, your proof is invalid.


    Linz_Hat <is> Linz_H that takes one param and copies it instead of
    two params and has an infinite loop at its accept state.

    Note, Linz_H_Hat CAN'T "Contradict" itself, as doesn't generate any
    truth values, only behavior. You are just showing that you don't
    understand the basics of the requirements, and seem to think that
    "close" is good enough for proofs.

    Linz_H_Hat(Linz_H_Hat) returns 0.

    --
    Copyright 2023 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 olcott@21:1/5 to Richard Damon on Mon Jul 3 13:49:43 2023
    XPost: comp.theory, sci.logic

    On 7/3/2023 1:25 PM, Richard Damon wrote:
    On 7/3/23 2:00 PM, olcott wrote:
    On 7/3/2023 11:26 AM, Richard Damon wrote:
    On 7/3/23 12:09 PM, olcott wrote:
    On 7/3/2023 10:58 AM, Richard Damon wrote:
    On 7/3/23 11:41 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 11:10 AM, olcott wrote:
    At the Turing machine level any D can make it impossible for a >>>>>>>> particular H to be unable to correctly report on the behavior of >>>>>>>> the
    directly executed D(D). Because D is a fixed constant finite
    string it
    cannot dynamically reconfigure itself to fool a different H.



    So, you don't understand the problem.

    D doesn't even exist as an input until you define the H

    So you want a TM to decide halting for an imaginary input?
    That is not the way that computation actually works.

    Nope, it must decide for ALL inputs, even those that haven't been
    'created' yet.

    Once you create H, you can create D. That will be one of the
    infinite set of possible inputs that H was designed to decide on.

    When we RUN H, the input exists. Until you decide on what H will
    be, we don't know which of all the possible inputs D will be.


    In computability theory and computational complexity theory, a
    decision
    problem is a computational problem that can be posed as a yes–no >>>>>> question of the input values.
    https://en.wikipedia.org/wiki/Decision_problem

    Right, and it must accept ALL inputs, it can take the input based
    on itself, which we don't know which one it will be until we define
    the decider.


    TM's do not take ideas held within the mind as their inputs, they
    only
    take fixed constant finite strings as inputs.


    Right, but since it takes ALL inputs, it can take an input based on
    itself,

    None-the-less you continue to assert that it must take ideas as inputs. >>>> It just doesn't work that way.


    Nope, Where did I say THAT.

    On 7/3/2023 10:58 AM, Richard Damon wrote:
    Nope, it must decide for ALL inputs, even those that haven't been
    'created' yet.


    Right, haven't been created at the time the decider is created, but will
    have been when it is run.


    Not unless the guy that wrote the decider also wrote its input.
    Until then the input you refer to is only imaginary.

    --
    Copyright 2023 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 olcott@21:1/5 to Richard Damon on Mon Jul 3 13:56:40 2023
    XPost: comp.theory, sci.logic

    On 7/3/2023 1:25 PM, Richard Damon wrote:
    On 7/3/23 2:03 PM, olcott wrote:
    On 7/3/2023 11:26 AM, Richard Damon wrote:
    On 7/3/23 12:05 PM, olcott wrote:
    On 7/3/2023 10:58 AM, Richard Damon wrote:
    On 7/3/23 11:44 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 10:42 AM, olcott wrote:
    On 7/3/2023 8:13 AM, Richard Damon wrote:
    On 7/2/23 11:10 PM, olcott wrote:

    Only when I show you are wrong. Actually try to answer my
    objections


    What about a three valued decider?
    0=undecidable
    1=halting
    2=not halting


    Doesn't meet the definition of a Halt Decider.


    Because these are semantic properties based on the behavior of
    the input it does refute Rice.

    Nope. Rice's theorem doesn't allow for an 'undecidable' output
    state either.

    Either the input is or is not something that is in the set defined
    by the function/language defined.

    Undecidable is just admitting that Rice is true.


    Undecidable <is> a semantic property.

    Source of that Claim?

    And you aren't saying the Undecidable <IS> a semantic property, but
    is an answer for if an input <HAS> some specific semantic property.

    In computability theory, Rice's theorem states that all non-trivial
    semantic properties of programs are undecidable. A semantic property is
    one about the program's behavior
    https://en.wikipedia.org/wiki/Rice%27s_theorem

    Undecidable <is> a semantic property of the finite string pair: {H,D}.


    As I mentioned, many simple descriptions get it wrong. Note, later in
    the same page it says:

    It is important to note that Rice's theorem does not concern the
    properties of machines or programs; it concerns properties of functions
    and languages.


    H correctly accepts every language specified by the pair: {H, *}
    (where the first element is the machine description of H and the
    second element is any other machine description) or rejects this
    pair as undecidable.


    --
    Copyright 2023 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 Mon Jul 3 15:58:26 2023
    XPost: comp.theory, sci.logic

    On 7/3/23 2:49 PM, olcott wrote:
    On 7/3/2023 1:25 PM, Richard Damon wrote:
    On 7/3/23 2:00 PM, olcott wrote:
    On 7/3/2023 11:26 AM, Richard Damon wrote:
    On 7/3/23 12:09 PM, olcott wrote:
    On 7/3/2023 10:58 AM, Richard Damon wrote:
    On 7/3/23 11:41 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 11:10 AM, olcott wrote:
    At the Turing machine level any D can make it impossible for a >>>>>>>>> particular H to be unable to correctly report on the behavior >>>>>>>>> of the
    directly executed D(D). Because D is a fixed constant finite >>>>>>>>> string it
    cannot dynamically reconfigure itself to fool a different H. >>>>>>>>>


    So, you don't understand the problem.

    D doesn't even exist as an input until you define the H

    So you want a TM to decide halting for an imaginary input?
    That is not the way that computation actually works.

    Nope, it must decide for ALL inputs, even those that haven't been
    'created' yet.

    Once you create H, you can create D. That will be one of the
    infinite set of possible inputs that H was designed to decide on.

    When we RUN H, the input exists. Until you decide on what H will
    be, we don't know which of all the possible inputs D will be.


    In computability theory and computational complexity theory, a
    decision
    problem is a computational problem that can be posed as a yes–no >>>>>>> question of the input values.
    https://en.wikipedia.org/wiki/Decision_problem

    Right, and it must accept ALL inputs, it can take the input based
    on itself, which we don't know which one it will be until we
    define the decider.


    TM's do not take ideas held within the mind as their inputs, they >>>>>>> only
    take fixed constant finite strings as inputs.


    Right, but since it takes ALL inputs, it can take an input based
    on itself,

    None-the-less you continue to assert that it must take ideas as
    inputs.
    It just doesn't work that way.


    Nope, Where did I say THAT.

    On 7/3/2023 10:58 AM, Richard Damon wrote:
    Nope, it must decide for ALL inputs, even those that haven't been
    'created' yet.


    Right, haven't been created at the time the decider is created, but
    will have been when it is run.


    Not unless the guy that wrote the decider also wrote its input.
    Until then the input you refer to is only imaginary.


    Why do you say that? As I said, it actually exist when we run the
    decider on it.

    There is NO requirement that the creater of the decider to have "seen"
    all the inputs that it might have to handle.

    Or don't you understand the requirement to handle *ALL* inputs?

    Remember, that ALL inputs represents an INFINITE number of possible
    inputs, so they CAN'T all be listed, or "exist" yet.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Richard Damon on Mon Jul 3 15:03:44 2023
    XPost: comp.theory, sci.logic

    On 7/3/2023 2:58 PM, Richard Damon wrote:
    On 7/3/23 2:49 PM, olcott wrote:
    On 7/3/2023 1:25 PM, Richard Damon wrote:
    On 7/3/23 2:00 PM, olcott wrote:
    On 7/3/2023 11:26 AM, Richard Damon wrote:
    On 7/3/23 12:09 PM, olcott wrote:
    On 7/3/2023 10:58 AM, Richard Damon wrote:
    On 7/3/23 11:41 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 11:10 AM, olcott wrote:
    At the Turing machine level any D can make it impossible for a >>>>>>>>>> particular H to be unable to correctly report on the behavior >>>>>>>>>> of the
    directly executed D(D). Because D is a fixed constant finite >>>>>>>>>> string it
    cannot dynamically reconfigure itself to fool a different H. >>>>>>>>>>


    So, you don't understand the problem.

    D doesn't even exist as an input until you define the H

    So you want a TM to decide halting for an imaginary input?
    That is not the way that computation actually works.

    Nope, it must decide for ALL inputs, even those that haven't been >>>>>>> 'created' yet.

    Once you create H, you can create D. That will be one of the
    infinite set of possible inputs that H was designed to decide on. >>>>>>>
    When we RUN H, the input exists. Until you decide on what H will >>>>>>> be, we don't know which of all the possible inputs D will be.


    In computability theory and computational complexity theory, a >>>>>>>> decision
    problem is a computational problem that can be posed as a yes–no >>>>>>>> question of the input values.
    https://en.wikipedia.org/wiki/Decision_problem

    Right, and it must accept ALL inputs, it can take the input based >>>>>>> on itself, which we don't know which one it will be until we
    define the decider.


    TM's do not take ideas held within the mind as their inputs,
    they only
    take fixed constant finite strings as inputs.


    Right, but since it takes ALL inputs, it can take an input based >>>>>>> on itself,

    None-the-less you continue to assert that it must take ideas as
    inputs.
    It just doesn't work that way.


    Nope, Where did I say THAT.

    On 7/3/2023 10:58 AM, Richard Damon wrote:
    Nope, it must decide for ALL inputs, even those that haven't been
    'created' yet.


    Right, haven't been created at the time the decider is created, but
    will have been when it is run.


    Not unless the guy that wrote the decider also wrote its input.
    Until then the input you refer to is only imaginary.


    Why do you say that? As I said, it actually exist when we run the
    decider on it.


    It only exists in the imagination until someone actually creates the
    finite string.

    --
    Copyright 2023 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 olcott@21:1/5 to Richard Damon on Mon Jul 3 15:08:55 2023
    XPost: comp.theory, sci.logic

    On 7/3/2023 2:58 PM, Richard Damon wrote:
    On 7/3/23 2:56 PM, olcott wrote:
    On 7/3/2023 1:25 PM, Richard Damon wrote:
    On 7/3/23 2:03 PM, olcott wrote:
    On 7/3/2023 11:26 AM, Richard Damon wrote:
    On 7/3/23 12:05 PM, olcott wrote:
    On 7/3/2023 10:58 AM, Richard Damon wrote:
    On 7/3/23 11:44 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 10:42 AM, olcott wrote:
    On 7/3/2023 8:13 AM, Richard Damon wrote:
    On 7/2/23 11:10 PM, olcott wrote:

    Only when I show you are wrong. Actually try to answer my >>>>>>>>>>> objections


    What about a three valued decider?
    0=undecidable
    1=halting
    2=not halting


    Doesn't meet the definition of a Halt Decider.


    Because these are semantic properties based on the behavior of >>>>>>>> the input it does refute Rice.

    Nope. Rice's theorem doesn't allow for an 'undecidable' output
    state either.

    Either the input is or is not something that is in the set
    defined by the function/language defined.

    Undecidable is just admitting that Rice is true.


    Undecidable <is> a semantic property.

    Source of that Claim?

    And you aren't saying the Undecidable <IS> a semantic property, but
    is an answer for if an input <HAS> some specific semantic property.

    In computability theory, Rice's theorem states that all non-trivial
    semantic properties of programs are undecidable. A semantic property is >>>> one about the program's behavior
    https://en.wikipedia.org/wiki/Rice%27s_theorem

    Undecidable <is> a semantic property of the finite string pair: {H,D}. >>>>

    As I mentioned, many simple descriptions get it wrong. Note, later in
    the same page it says:

    It is important to note that Rice's theorem does not concern the
    properties of machines or programs; it concerns properties of
    functions and languages.


    H correctly accepts every language specified by the pair: {H, *}
    (where the first element is the machine description of H and the
    second element is any other machine description) or rejects this
    pair as undecidable.



    So, you are admitting you don't understand what you are saying.

    D isn't "undecidable" but always has definite behavior based on the
    behavior of the definite machine H that it was based on (and thus you
    are being INTENTIONALLY dupicious by now calling H to be a some sort of
    other decider).

    Since you claim that Halt-Decider-H "Correctly" returned false for
    H(D,D) we know that D(D) Halts, so D the problem of D has an answer so
    hard to call "undecidable"

    Again, what is the definition of your "Language", and why do you call
    {H,D} as UNDECIDABLE, since H will be a FIXED DEFINED decider that is
    just WRONG about its input, that isn't "undecidable".

    {H,D} undecidable means that D is undecidable for H, which is an
    verified fact. The set of {H,*} finite string pairs do define a
    language. Decidability <is> a semantic property because it
    can only be correctly decided on the basis of behavior.

    --
    Copyright 2023 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 olcott@21:1/5 to Richard Damon on Mon Jul 3 15:45:14 2023
    XPost: comp.theory, sci.logic

    On 7/3/2023 2:58 PM, Richard Damon wrote:
    On 7/3/23 2:56 PM, olcott wrote:
    On 7/3/2023 1:25 PM, Richard Damon wrote:
    On 7/3/23 2:03 PM, olcott wrote:
    On 7/3/2023 11:26 AM, Richard Damon wrote:
    On 7/3/23 12:05 PM, olcott wrote:
    On 7/3/2023 10:58 AM, Richard Damon wrote:
    On 7/3/23 11:44 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 10:42 AM, olcott wrote:
    On 7/3/2023 8:13 AM, Richard Damon wrote:
    On 7/2/23 11:10 PM, olcott wrote:

    Only when I show you are wrong. Actually try to answer my >>>>>>>>>>> objections


    What about a three valued decider?
    0=undecidable
    1=halting
    2=not halting


    Doesn't meet the definition of a Halt Decider.


    Because these are semantic properties based on the behavior of >>>>>>>> the input it does refute Rice.

    Nope. Rice's theorem doesn't allow for an 'undecidable' output
    state either.

    Either the input is or is not something that is in the set
    defined by the function/language defined.

    Undecidable is just admitting that Rice is true.


    Undecidable <is> a semantic property.

    Source of that Claim?

    And you aren't saying the Undecidable <IS> a semantic property, but
    is an answer for if an input <HAS> some specific semantic property.

    In computability theory, Rice's theorem states that all non-trivial
    semantic properties of programs are undecidable. A semantic property is >>>> one about the program's behavior
    https://en.wikipedia.org/wiki/Rice%27s_theorem

    Undecidable <is> a semantic property of the finite string pair: {H,D}. >>>>

    As I mentioned, many simple descriptions get it wrong. Note, later in
    the same page it says:

    It is important to note that Rice's theorem does not concern the
    properties of machines or programs; it concerns properties of
    functions and languages.


    H correctly accepts every language specified by the pair: {H, *}
    (where the first element is the machine description of H and the
    second element is any other machine description) or rejects this
    pair as undecidable.



    So, you are admitting you don't understand what you are saying.

    D isn't "undecidable" but always has definite behavior based on the
    behavior of the definite machine H that it was based on (and thus you
    are being INTENTIONALLY dupicious by now calling H to be a some sort of
    other decider).

    Since you claim that Halt-Decider-H "Correctly" returned false for
    H(D,D) we know that D(D) Halts, so D the problem of D has an answer so
    hard to call "undecidable"

    Again, what is the definition of your "Language", and why do you call
    {H,D} as UNDECIDABLE, since H will be a FIXED DEFINED decider that is
    just WRONG about its input, that isn't "undecidable".


    Using Rogers' characterization of acceptable programming systems, Rice's theorem may essentially be generalized from Turing machines to most
    computer programming languages: there exists no automatic method that
    decides with generality non-trivial questions on the behavior of
    computer programs. https://en.wikipedia.org/wiki/Rice%27s_theorem

    H correctly divides inputs into
    (a) Halting
    (b) Not halting
    (c) Cannot be decided by H

    --
    Copyright 2023 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 olcott@21:1/5 to Richard Damon on Mon Jul 3 15:22:57 2023
    XPost: comp.theory, sci.logic

    On 7/3/2023 2:58 PM, Richard Damon wrote:
    On 7/3/23 2:48 PM, olcott wrote:
    On 7/3/2023 1:25 PM, Richard Damon wrote:
    On 7/3/23 1:57 PM, olcott wrote:
    On 7/3/2023 11:26 AM, Richard Damon wrote:
    On 7/3/23 12:11 PM, olcott wrote:
    On 7/3/2023 11:01 AM, Richard Damon wrote:
    On 7/3/23 11:56 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 10:45 AM, olcott wrote:
    On 7/3/2023 9:24 AM, Richard Damon wrote:
    On 7/3/23 9:47 AM, olcott wrote:
    On 7/3/2023 8:14 AM, Richard Damon wrote:
    On 7/2/23 10:48 PM, olcott wrote:
    On 7/2/2023 9:41 PM, Richard Damon wrote:
    On 7/2/23 10:01 PM, olcott wrote:
    On 7/2/2023 8:40 PM, Richard Damon wrote:
    On 7/2/23 8:45 PM, olcott wrote:
    A single H can consistently correctly determine >>>>>>>>>>>>>>>>>> whether or not its input
    is pathological relative to itself. When H(D,D) is >>>>>>>>>>>>>>>>>> invoked in
    decidability decider mode determines that D is >>>>>>>>>>>>>>>>>> pathological relative to
    itself this enables a batch file to invoke H1(D,D) to >>>>>>>>>>>>>>>>>> get the actual
    behavior of the directly executed D(D). H1 is >>>>>>>>>>>>>>>>>> identical to H except for
    the pathological relationship to H.



    And does an input D that uses this FULL algorithm give >>>>>>>>>>>>>>>>> your algorithm problems?

    Since H(D,D) will (apparently) determine that the input >>>>>>>>>>>>>>>>> is pathological, and thus defer to H1(D,D), then when >>>>>>>>>>>>>>>>> we actually run D, appearently it will get that same >>>>>>>>>>>>>>>>> answer from H1 and do the opposite of it, and thus H1 >>>>>>>>>>>>>>>>> will be wrong.

    Remember, the "Pathological" program is built on a copy >>>>>>>>>>>>>>>>> of the ACTUAL program that you ask to decide on it, >>>>>>>>>>>>>>>>> including ALL of its "tricks", including things like >>>>>>>>>>>>>>>>> this "batch processing".

    You seem to be assuming that there is some "Operationg >>>>>>>>>>>>>>>>> System" outside the Decider - Input structure, but >>>>>>>>>>>>>>>>> there isn't, at least not one that can affect the >>>>>>>>>>>>>>>>> answer of the problem.

    I spent 12 hours a day for the last 10 days getting the >>>>>>>>>>>>>>>> copy the input
    working. When H(D,D) (in decidability decider mode) >>>>>>>>>>>>>>>> detects that its
    input is in the well defined set of pathological inputs >>>>>>>>>>>>>>>> it returns 0
    indicating that its input is undecidable. The batch file >>>>>>>>>>>>>>>> that invoked H
    then knows to invoke H1(D,D) to correctly report that >>>>>>>>>>>>>>>> D(D) halts.

    This solution does seem to work correctly on every >>>>>>>>>>>>>>>> conventional proof in
    every textbook.


    So, did you make your "conventional proof" template >>>>>>>>>>>>>>> actually use a copy of your ACTUAL decider (which seems >>>>>>>>>>>>>>> to be your "batch file" not the C funciton H), or are you >>>>>>>>>>>>>>> just admitting that you wasted 120 hours looking at the >>>>>>>>>>>>>>> wrong thing because you have made yourself intentionally >>>>>>>>>>>>>>> ignorant of the subject so you don't understand what you >>>>>>>>>>>>>>> are trying to do.

    New_D copies its input and simulates its input with its >>>>>>>>>>>>>> input.
    It never sees New_H.


    Why not? Since New_H is the thing that is considered the >>>>>>>>>>>>> "Correct Halt Decider", New_D needs to be built on it. >>>>>>>>>>>>>

    New_H is embedded within New_D (as its middle states) just the >>>>>>>>>>>> way it is supposed to be. The question is: Does New_H(New_H) >>>>>>>>>>>> halt?

    The only difference at the source code level is:
    (a) New_H copies its input, thus takes one param.
    (b) New_H has an infinite loop at its accept state.

    So, how is New_H a halt decider then?

    typo
    The only difference at the source code level is:
    (a) New_D copies its input, thus takes one param.
    (b) New_D has an infinite loop at its accept state.
    Other than that (at the source-code level) New_D is exactly New_H >>>>>>>>>>


    But New_D needs to call New_H,

    Not in the Peter Linz proof:
    https://www.liarparadox.org/Linz_Proof.pdf

    In the Linz proof a copy of H is directly embedded
    within Ĥ at this state: Ĥq0 Wm Wm
    The original H remains unchanged.

    The halting problem is about undecidable inputs, it is not about >>>>>>>> inserting bugs into a halt decider to make it cease to function. >>>>>>>>


    Right, and in Linz, H is the decider that is claimed to give the >>>>>>> right answer.

    That isn't 'H' in your system, but the script that decides
    whether to use H or H1.

    Your error is in calling the wrong thing 'H'

    You are just showing you are lying by using the wrong name for
    things.

    You are using double-talk in a lame attempt to show that
    Linz H cannot correctly determine the halt status of Linz Ĥ.


    So you agree with the Theorem.

    No 'Linz H' can exist that correctly decides the halt status of
    Linz Ĥ applied to the description of Linz Ĥ.

    That is EXACTLY the consequence of the Halting Theorem.


    Please show an ACTUAL 'Linz H' that correctly gets the results of
    the 'Linz Ĥ' built on it. You keep on changing H and trying to use
    the old Ĥ which just fails to meet the requirement of the proof,
    likely because you just don't understand the theory involved.

    It took me two years to figure out a clean way to copy the input to
    Linz_H_Hat and not have the system crash. Relative to Linz_H_Hat
    Linz_H is H1. Now Linz_H_Hat only contradicts itself.


    So, you are admitting that you actually can't do what is required?

    Copying the input should be trivial,

    The relative addressing of the x86 language causes all function
    calls to call the wrong address.

    Only because you aren't interpreting the input properly, but in a
    non-Turing Complete manner.

    As I said, the input description should be a chunck of code in a virtual address space with a header that tells where that code is supposed to be considered to be located at.


    as the input should be a representation that packages a full program
    in its own virtual environment, so a simple bit by bit copy to empty
    ram will work. Your problem is that you don't put the input into its
    own virtual address space, so you have pathological interactions.

    Linz_H_Hat must be built on the exact code base that is deciding on
    it, in this case H, since you just said it isn't, your proof is invalid. >>>

    Linz_Hat <is> Linz_H that takes one param  and copies it instead of
    two params and has an infinite loop at its accept state.

    So, Two things that are different are exactly the same?


    It exactly matches the Linz spec.

    You don't seem to understand what you are doing.

    Linz_H_Hat (not Linz_Hat) is a Turing Machine with a defined behavior.
    That behavior is a function of its input, but hasn't been assigned any "meaning".

    Linz_H is a Turing Machine (if it actually can exist) that has a defined meaning/requirement for its final states. Linz_H, to meet its
    requirements, MUST go to Qy if the input represents a Halting
    Computation, and MUST go to Qn if the input represents a non-halting computation.

    Since Linz_H has actual requirements, a claimed implementation of it can
    be checked to see if it actually meets the requirements, and perhaps we
    can determine if it is possible to meet them.


    Note, Linz_H_Hat CAN'T "Contradict" itself, as doesn't generate any
    truth values, only behavior. You are just showing that you don't
    understand the basics of the requirements, and seem to think that
    "close" is good enough for proofs.

    Linz_H_Hat(Linz_H_Hat) returns 0.

    Actually no. Linz_H_Hat(Linz_H_Hat) halts at state Qn, which has NO
    defined meaning for Linz_H_Hat as it isn't defined to be a decider.

    Linz_H and Linz_H_Hat are C functions.
    Linz:H and Linz:Ĥ are Turing machines.

    Linz_H and Linz:H are both directly embedded within a copy of
    Linz_H_Hat and Linz:Ĥ thus a return value of 0 or a transition
    to Ĥ.qn still means not halting.

    This allows Linz_H and Linz:H correctly report on the actual
    behavior of their input.


    --
    Copyright 2023 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 Mon Jul 3 17:07:45 2023
    XPost: comp.theory, sci.logic

    On 7/3/23 4:03 PM, olcott wrote:
    On 7/3/2023 2:58 PM, Richard Damon wrote:
    On 7/3/23 2:49 PM, olcott wrote:
    On 7/3/2023 1:25 PM, Richard Damon wrote:
    On 7/3/23 2:00 PM, olcott wrote:
    On 7/3/2023 11:26 AM, Richard Damon wrote:
    On 7/3/23 12:09 PM, olcott wrote:
    On 7/3/2023 10:58 AM, Richard Damon wrote:
    On 7/3/23 11:41 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 11:10 AM, olcott wrote:
    At the Turing machine level any D can make it impossible for a >>>>>>>>>>> particular H to be unable to correctly report on the behavior >>>>>>>>>>> of the
    directly executed D(D). Because D is a fixed constant finite >>>>>>>>>>> string it
    cannot dynamically reconfigure itself to fool a different H. >>>>>>>>>>>


    So, you don't understand the problem.

    D doesn't even exist as an input until you define the H

    So you want a TM to decide halting for an imaginary input?
    That is not the way that computation actually works.

    Nope, it must decide for ALL inputs, even those that haven't
    been 'created' yet.

    Once you create H, you can create D. That will be one of the
    infinite set of possible inputs that H was designed to decide on. >>>>>>>>
    When we RUN H, the input exists. Until you decide on what H will >>>>>>>> be, we don't know which of all the possible inputs D will be.


    In computability theory and computational complexity theory, a >>>>>>>>> decision
    problem is a computational problem that can be posed as a yes–no >>>>>>>>> question of the input values.
    https://en.wikipedia.org/wiki/Decision_problem

    Right, and it must accept ALL inputs, it can take the input
    based on itself, which we don't know which one it will be until >>>>>>>> we define the decider.


    TM's do not take ideas held within the mind as their inputs, >>>>>>>>> they only
    take fixed constant finite strings as inputs.


    Right, but since it takes ALL inputs, it can take an input based >>>>>>>> on itself,

    None-the-less you continue to assert that it must take ideas as
    inputs.
    It just doesn't work that way.


    Nope, Where did I say THAT.

    On 7/3/2023 10:58 AM, Richard Damon wrote:
    Nope, it must decide for ALL inputs, even those that haven't been >>>>>  > 'created' yet.


    Right, haven't been created at the time the decider is created, but
    will have been when it is run.


    Not unless the guy that wrote the decider also wrote its input.
    Until then the input you refer to is only imaginary.


    Why do you say that? As I said, it actually exist when we run the
    decider on it.


    It only exists in the imagination until someone actually creates the
    finite string.


    So?

    We CAN create it to give to H to ask it the question.

    Thus, what is the problem with doing that?


    The fact that you can imagine ways to do it wrong doesn't mean you can't
    do it right.

    This is just more of your backwards logic, showing you have been just
    slinging more Red Herring because you can't handle the actual issue,
    that your H will ALWAYS get the wrong answer when asked this question
    (if it answers at all, which just shows another way to be wrong).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Richard Damon on Mon Jul 3 16:19:22 2023
    XPost: comp.theory, sci.logic

    On 7/3/2023 4:07 PM, Richard Damon wrote:
    On 7/3/23 4:45 PM, olcott wrote:
    On 7/3/2023 2:58 PM, Richard Damon wrote:
    On 7/3/23 2:56 PM, olcott wrote:
    On 7/3/2023 1:25 PM, Richard Damon wrote:
    On 7/3/23 2:03 PM, olcott wrote:
    On 7/3/2023 11:26 AM, Richard Damon wrote:
    On 7/3/23 12:05 PM, olcott wrote:
    On 7/3/2023 10:58 AM, Richard Damon wrote:
    On 7/3/23 11:44 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 10:42 AM, olcott wrote:
    On 7/3/2023 8:13 AM, Richard Damon wrote:
    On 7/2/23 11:10 PM, olcott wrote:

    Only when I show you are wrong. Actually try to answer my >>>>>>>>>>>>> objections


    What about a three valued decider?
    0=undecidable
    1=halting
    2=not halting


    Doesn't meet the definition of a Halt Decider.


    Because these are semantic properties based on the behavior of >>>>>>>>>> the input it does refute Rice.

    Nope. Rice's theorem doesn't allow for an 'undecidable' output >>>>>>>>> state either.

    Either the input is or is not something that is in the set
    defined by the function/language defined.

    Undecidable is just admitting that Rice is true.


    Undecidable <is> a semantic property.

    Source of that Claim?

    And you aren't saying the Undecidable <IS> a semantic property,
    but is an answer for if an input <HAS> some specific semantic
    property.

    In computability theory, Rice's theorem states that all non-trivial >>>>>> semantic properties of programs are undecidable. A semantic
    property is
    one about the program's behavior
    https://en.wikipedia.org/wiki/Rice%27s_theorem

    Undecidable <is> a semantic property of the finite string pair:
    {H,D}.


    As I mentioned, many simple descriptions get it wrong. Note, later
    in the same page it says:

    It is important to note that Rice's theorem does not concern the
    properties of machines or programs; it concerns properties of
    functions and languages.


    H correctly accepts every language specified by the pair: {H, *}
    (where the first element is the machine description of H and the
    second element is any other machine description) or rejects this
    pair as undecidable.



    So, you are admitting you don't understand what you are saying.

    D isn't "undecidable" but always has definite behavior based on the
    behavior of the definite machine H that it was based on (and thus you
    are being INTENTIONALLY dupicious by now calling H to be a some sort
    of other decider).

    Since you claim that Halt-Decider-H "Correctly" returned false for
    H(D,D) we know that D(D) Halts, so D the problem of D has an answer
    so hard to call "undecidable"

    Again, what is the definition of your "Language", and why do you call
    {H,D} as UNDECIDABLE, since H will be a FIXED DEFINED decider that is
    just WRONG about its input, that isn't "undecidable".


    Using Rogers' characterization of acceptable programming systems, Rice's
    theorem may essentially be generalized from Turing machines to most
    computer programming languages: there exists no automatic method that
    decides with generality non-trivial questions on the behavior of
    computer programs. https://en.wikipedia.org/wiki/Rice%27s_theorem

    H correctly divides inputs into
    (a) Halting
    (b) Not halting
    (c) Cannot be decided by H


    And where do you see anything that allows H to be "correct" in giving
    answer (c)?

    The specific input either represents a machine that does (a) or does
    (b), so in no case is the results of "it can not be decided" be correct.

    You are just showing that you fundamentally don't understand what you
    are talking about.

    The question follows the rule of the excluded middle, so there is no
    valid answer (c).

    H is a correct halting decidability decider for itself.
    Rice says that is impossible, thus Rice is wrong.




    --
    Copyright 2023 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 Mon Jul 3 17:17:23 2023
    XPost: comp.theory, sci.logic

    On 7/3/23 4:22 PM, olcott wrote:
    On 7/3/2023 2:58 PM, Richard Damon wrote:
    On 7/3/23 2:48 PM, olcott wrote:
    On 7/3/2023 1:25 PM, Richard Damon wrote:
    On 7/3/23 1:57 PM, olcott wrote:
    On 7/3/2023 11:26 AM, Richard Damon wrote:
    On 7/3/23 12:11 PM, olcott wrote:
    On 7/3/2023 11:01 AM, Richard Damon wrote:
    On 7/3/23 11:56 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 10:45 AM, olcott wrote:
    On 7/3/2023 9:24 AM, Richard Damon wrote:
    On 7/3/23 9:47 AM, olcott wrote:
    On 7/3/2023 8:14 AM, Richard Damon wrote:
    On 7/2/23 10:48 PM, olcott wrote:
    On 7/2/2023 9:41 PM, Richard Damon wrote:
    On 7/2/23 10:01 PM, olcott wrote:
    On 7/2/2023 8:40 PM, Richard Damon wrote:
    On 7/2/23 8:45 PM, olcott wrote:
    A single H can consistently correctly determine >>>>>>>>>>>>>>>>>>> whether or not its input
    is pathological relative to itself. When H(D,D) is >>>>>>>>>>>>>>>>>>> invoked in
    decidability decider mode determines that D is >>>>>>>>>>>>>>>>>>> pathological relative to
    itself this enables a batch file to invoke H1(D,D) to >>>>>>>>>>>>>>>>>>> get the actual
    behavior of the directly executed D(D). H1 is >>>>>>>>>>>>>>>>>>> identical to H except for
    the pathological relationship to H.



    And does an input D that uses this FULL algorithm give >>>>>>>>>>>>>>>>>> your algorithm problems?

    Since H(D,D) will (apparently) determine that the >>>>>>>>>>>>>>>>>> input is pathological, and thus defer to H1(D,D), then >>>>>>>>>>>>>>>>>> when we actually run D, appearently it will get that >>>>>>>>>>>>>>>>>> same answer from H1 and do the opposite of it, and >>>>>>>>>>>>>>>>>> thus H1 will be wrong.

    Remember, the "Pathological" program is built on a >>>>>>>>>>>>>>>>>> copy of the ACTUAL program that you ask to decide on >>>>>>>>>>>>>>>>>> it, including ALL of its "tricks", including things >>>>>>>>>>>>>>>>>> like this "batch processing".

    You seem to be assuming that there is some "Operationg >>>>>>>>>>>>>>>>>> System" outside the Decider - Input structure, but >>>>>>>>>>>>>>>>>> there isn't, at least not one that can affect the >>>>>>>>>>>>>>>>>> answer of the problem.

    I spent 12 hours a day for the last 10 days getting the >>>>>>>>>>>>>>>>> copy the input
    working. When H(D,D) (in decidability decider mode) >>>>>>>>>>>>>>>>> detects that its
    input is in the well defined set of pathological inputs >>>>>>>>>>>>>>>>> it returns 0
    indicating that its input is undecidable. The batch >>>>>>>>>>>>>>>>> file that invoked H
    then knows to invoke H1(D,D) to correctly report that >>>>>>>>>>>>>>>>> D(D) halts.

    This solution does seem to work correctly on every >>>>>>>>>>>>>>>>> conventional proof in
    every textbook.


    So, did you make your "conventional proof" template >>>>>>>>>>>>>>>> actually use a copy of your ACTUAL decider (which seems >>>>>>>>>>>>>>>> to be your "batch file" not the C funciton H), or are >>>>>>>>>>>>>>>> you just admitting that you wasted 120 hours looking at >>>>>>>>>>>>>>>> the wrong thing because you have made yourself >>>>>>>>>>>>>>>> intentionally ignorant of the subject so you don't >>>>>>>>>>>>>>>> understand what you are trying to do.

    New_D copies its input and simulates its input with its >>>>>>>>>>>>>>> input.
    It never sees New_H.


    Why not? Since New_H is the thing that is considered the >>>>>>>>>>>>>> "Correct Halt Decider", New_D needs to be built on it. >>>>>>>>>>>>>>

    New_H is embedded within New_D (as its middle states) just the >>>>>>>>>>>>> way it is supposed to be. The question is: Does
    New_H(New_H) halt?

    The only difference at the source code level is:
    (a) New_H copies its input, thus takes one param.
    (b) New_H has an infinite loop at its accept state.

    So, how is New_H a halt decider then?

    typo
    The only difference at the source code level is:
    (a) New_D copies its input, thus takes one param.
    (b) New_D has an infinite loop at its accept state.
    Other than that (at the source-code level) New_D is exactly >>>>>>>>>>> New_H



    But New_D needs to call New_H,

    Not in the Peter Linz proof:
    https://www.liarparadox.org/Linz_Proof.pdf

    In the Linz proof a copy of H is directly embedded
    within Ĥ at this state: Ĥq0 Wm Wm
    The original H remains unchanged.

    The halting problem is about undecidable inputs, it is not about >>>>>>>>> inserting bugs into a halt decider to make it cease to function. >>>>>>>>>


    Right, and in Linz, H is the decider that is claimed to give the >>>>>>>> right answer.

    That isn't 'H' in your system, but the script that decides
    whether to use H or H1.

    Your error is in calling the wrong thing 'H'

    You are just showing you are lying by using the wrong name for >>>>>>>> things.

    You are using double-talk in a lame attempt to show that
    Linz H cannot correctly determine the halt status of Linz Ĥ.


    So you agree with the Theorem.

    No 'Linz H' can exist that correctly decides the halt status of
    Linz Ĥ applied to the description of Linz Ĥ.

    That is EXACTLY the consequence of the Halting Theorem.


    Please show an ACTUAL 'Linz H' that correctly gets the results of
    the 'Linz Ĥ' built on it. You keep on changing H and trying to use >>>>>> the old Ĥ which just fails to meet the requirement of the proof,
    likely because you just don't understand the theory involved.

    It took me two years to figure out a clean way to copy the input to
    Linz_H_Hat and not have the system crash. Relative to Linz_H_Hat
    Linz_H is H1. Now Linz_H_Hat only contradicts itself.


    So, you are admitting that you actually can't do what is required?

    Copying the input should be trivial,

    The relative addressing of the x86 language causes all function
    calls to call the wrong address.

    Only because you aren't interpreting the input properly, but in a
    non-Turing Complete manner.

    As I said, the input description should be a chunck of code in a
    virtual address space with a header that tells where that code is
    supposed to be considered to be located at.


    as the input should be a representation that packages a full program
    in its own virtual environment, so a simple bit by bit copy to empty
    ram will work. Your problem is that you don't put the input into its
    own virtual address space, so you have pathological interactions.

    Linz_H_Hat must be built on the exact code base that is deciding on
    it, in this case H, since you just said it isn't, your proof is
    invalid.


    Linz_Hat <is> Linz_H that takes one param  and copies it instead of
    two params and has an infinite loop at its accept state.

    So, Two things that are different are exactly the same?


    It exactly matches the Linz spec.

    You don't seem to understand what you are doing.

    Linz_H_Hat (not Linz_Hat) is a Turing Machine with a defined behavior.
    That behavior is a function of its input, but hasn't been assigned any
    "meaning".

    Linz_H is a Turing Machine (if it actually can exist) that has a
    defined meaning/requirement for its final states. Linz_H, to meet its
    requirements, MUST go to Qy if the input represents a Halting
    Computation, and MUST go to Qn if the input represents a non-halting
    computation.

    Since Linz_H has actual requirements, a claimed implementation of it
    can be checked to see if it actually meets the requirements, and
    perhaps we can determine if it is possible to meet them.


    Note, Linz_H_Hat CAN'T "Contradict" itself, as doesn't generate any
    truth values, only behavior. You are just showing that you don't
    understand the basics of the requirements, and seem to think that
    "close" is good enough for proofs.

    Linz_H_Hat(Linz_H_Hat) returns 0.

    Actually no. Linz_H_Hat(Linz_H_Hat) halts at state Qn, which has NO
    defined meaning for Linz_H_Hat as it isn't defined to be a decider.

    Linz_H and Linz_H_Hat are C functions.
    Linz:H and Linz:Ĥ are Turing machines.

    So, inventing new terminology without introduction, thus showing you are
    being intentionally deceptive.


    Linz_H and Linz:H are both directly embedded within a copy of
    Linz_H_Hat and Linz:Ĥ thus a return value of 0 or a transition
    to Ĥ.qn still means not halting.

    No, because Linz_H_Hat / Linz:Ĥ are not "Halt Deciders" so there return
    value has no meaning.

    Ĥ has no meaning, so it can't be "incorrect" or contradicted.


    This allows Linz_H and Linz:H correctly report on the actual
    behavior of their input.



    No, since BOTH have an input that when run will HALT, and both report
    that it will not, both are just wrong.

    Linz_H(Linz_H_Hat, Linz_H_Hat) is claimed to "correctly" return 0,
    indicating non=-halting. But when Linz_H_Hat calls Linz_H(Linz_H_Hat, Linz_H_Hat) and gets that returned 0, it Halts, so Linz_H is just wrong.

    You like to clai that Linz_H won't return that answer but it MUST as is
    needs to be a computation that only depends on its input, so it MUST
    always do the same thing.

    You have been asked before, show the first step in the direct execution
    of Linz_H(Linz_H_Hat, Linz_H_Hat) and the same call from within
    Linz_H_Hat that have different behavior, even though everything before
    them has been identical since the call to Linz_H.

    Until you provide this, you are just showing you are just a stupid
    pathological liar that claims impossible things must be true.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Mon Jul 3 17:34:19 2023
    XPost: comp.theory, sci.logic

    On 7/3/23 5:30 PM, olcott wrote:
    On 7/3/2023 4:07 PM, Richard Damon wrote:
    On 7/3/23 4:08 PM, olcott wrote:
    On 7/3/2023 2:58 PM, Richard Damon wrote:
    On 7/3/23 2:56 PM, olcott wrote:
    On 7/3/2023 1:25 PM, Richard Damon wrote:
    On 7/3/23 2:03 PM, olcott wrote:
    On 7/3/2023 11:26 AM, Richard Damon wrote:
    On 7/3/23 12:05 PM, olcott wrote:
    On 7/3/2023 10:58 AM, Richard Damon wrote:
    On 7/3/23 11:44 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 10:42 AM, olcott wrote:
    On 7/3/2023 8:13 AM, Richard Damon wrote:
    On 7/2/23 11:10 PM, olcott wrote:

    Only when I show you are wrong. Actually try to answer my >>>>>>>>>>>>>> objections


    What about a three valued decider?
    0=undecidable
    1=halting
    2=not halting


    Doesn't meet the definition of a Halt Decider.


    Because these are semantic properties based on the behavior of >>>>>>>>>>> the input it does refute Rice.

    Nope. Rice's theorem doesn't allow for an 'undecidable' output >>>>>>>>>> state either.

    Either the input is or is not something that is in the set >>>>>>>>>> defined by the function/language defined.

    Undecidable is just admitting that Rice is true.


    Undecidable <is> a semantic property.

    Source of that Claim?

    And you aren't saying the Undecidable <IS> a semantic property, >>>>>>>> but is an answer for if an input <HAS> some specific semantic
    property.

    In computability theory, Rice's theorem states that all non-trivial >>>>>>> semantic properties of programs are undecidable. A semantic
    property is
    one about the program's behavior
    https://en.wikipedia.org/wiki/Rice%27s_theorem

    Undecidable <is> a semantic property of the finite string pair:
    {H,D}.


    As I mentioned, many simple descriptions get it wrong. Note, later >>>>>> in the same page it says:

    It is important to note that Rice's theorem does not concern the
    properties of machines or programs; it concerns properties of
    functions and languages.


    H correctly accepts every language specified by the pair: {H, *}
    (where the first element is the machine description of H and the
    second element is any other machine description) or rejects this
    pair as undecidable.



    So, you are admitting you don't understand what you are saying.

    D isn't "undecidable" but always has definite behavior based on the
    behavior of the definite machine H that it was based on (and thus
    you are being INTENTIONALLY dupicious by now calling H to be a some
    sort of other decider).

    Since you claim that Halt-Decider-H "Correctly" returned false for
    H(D,D) we know that D(D) Halts, so D the problem of D has an answer
    so hard to call "undecidable"

    Again, what is the definition of your "Language", and why do you
    call {H,D} as UNDECIDABLE, since H will be a FIXED DEFINED decider
    that is just WRONG about its input, that isn't "undecidable".

    {H,D} undecidable means that D is undecidable for H, which is an
    verified fact. The set of {H,*} finite string pairs do define a
    language.  Decidability <is> a semantic property because it
    can only be correctly decided on the basis of behavior.


    What do you mean by "Undecidable by H?"


    H correctly determines that it cannot provide a halt status
    consistent with the behavior of the directly executed D(D).

    So? If it REALLY could detect that, it just needs to give the opposite
    answer.

    Or, in other words, you are just admitting that H is wrong.


    H is a decidability decider for itself, thus determining the
    semantic property of finite string pairs: {H,*}.
    0==Undecidable
    1==Decidable
    2==Decidable



    Which is just more nonsense words.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Richard Damon on Mon Jul 3 16:34:20 2023
    XPost: comp.theory, sci.logic

    On 7/3/2023 4:17 PM, Richard Damon wrote:
    On 7/3/23 4:22 PM, olcott wrote:
    On 7/3/2023 2:58 PM, Richard Damon wrote:
    On 7/3/23 2:48 PM, olcott wrote:
    On 7/3/2023 1:25 PM, Richard Damon wrote:
    On 7/3/23 1:57 PM, olcott wrote:
    On 7/3/2023 11:26 AM, Richard Damon wrote:
    On 7/3/23 12:11 PM, olcott wrote:
    On 7/3/2023 11:01 AM, Richard Damon wrote:
    On 7/3/23 11:56 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 10:45 AM, olcott wrote:
    On 7/3/2023 9:24 AM, Richard Damon wrote:
    On 7/3/23 9:47 AM, olcott wrote:
    On 7/3/2023 8:14 AM, Richard Damon wrote:
    On 7/2/23 10:48 PM, olcott wrote:
    On 7/2/2023 9:41 PM, Richard Damon wrote:
    On 7/2/23 10:01 PM, olcott wrote:
    On 7/2/2023 8:40 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>> On 7/2/23 8:45 PM, olcott wrote:
    A single H can consistently correctly determine >>>>>>>>>>>>>>>>>>>> whether or not its input
    is pathological relative to itself. When H(D,D) is >>>>>>>>>>>>>>>>>>>> invoked in
    decidability decider mode determines that D is >>>>>>>>>>>>>>>>>>>> pathological relative to
    itself this enables a batch file to invoke H1(D,D) >>>>>>>>>>>>>>>>>>>> to get the actual
    behavior of the directly executed D(D). H1 is >>>>>>>>>>>>>>>>>>>> identical to H except for
    the pathological relationship to H.



    And does an input D that uses this FULL algorithm >>>>>>>>>>>>>>>>>>> give your algorithm problems?

    Since H(D,D) will (apparently) determine that the >>>>>>>>>>>>>>>>>>> input is pathological, and thus defer to H1(D,D), >>>>>>>>>>>>>>>>>>> then when we actually run D, appearently it will get >>>>>>>>>>>>>>>>>>> that same answer from H1 and do the opposite of it, >>>>>>>>>>>>>>>>>>> and thus H1 will be wrong.

    Remember, the "Pathological" program is built on a >>>>>>>>>>>>>>>>>>> copy of the ACTUAL program that you ask to decide on >>>>>>>>>>>>>>>>>>> it, including ALL of its "tricks", including things >>>>>>>>>>>>>>>>>>> like this "batch processing".

    You seem to be assuming that there is some >>>>>>>>>>>>>>>>>>> "Operationg System" outside the Decider - Input >>>>>>>>>>>>>>>>>>> structure, but there isn't, at least not one that can >>>>>>>>>>>>>>>>>>> affect the answer of the problem.

    I spent 12 hours a day for the last 10 days getting >>>>>>>>>>>>>>>>>> the copy the input
    working. When H(D,D) (in decidability decider mode) >>>>>>>>>>>>>>>>>> detects that its
    input is in the well defined set of pathological >>>>>>>>>>>>>>>>>> inputs it returns 0
    indicating that its input is undecidable. The batch >>>>>>>>>>>>>>>>>> file that invoked H
    then knows to invoke H1(D,D) to correctly report that >>>>>>>>>>>>>>>>>> D(D) halts.

    This solution does seem to work correctly on every >>>>>>>>>>>>>>>>>> conventional proof in
    every textbook.


    So, did you make your "conventional proof" template >>>>>>>>>>>>>>>>> actually use a copy of your ACTUAL decider (which seems >>>>>>>>>>>>>>>>> to be your "batch file" not the C funciton H), or are >>>>>>>>>>>>>>>>> you just admitting that you wasted 120 hours looking at >>>>>>>>>>>>>>>>> the wrong thing because you have made yourself >>>>>>>>>>>>>>>>> intentionally ignorant of the subject so you don't >>>>>>>>>>>>>>>>> understand what you are trying to do.

    New_D copies its input and simulates its input with its >>>>>>>>>>>>>>>> input.
    It never sees New_H.


    Why not? Since New_H is the thing that is considered the >>>>>>>>>>>>>>> "Correct Halt Decider", New_D needs to be built on it. >>>>>>>>>>>>>>>

    New_H is embedded within New_D (as its middle states) just >>>>>>>>>>>>>> the
    way it is supposed to be. The question is: Does
    New_H(New_H) halt?

    The only difference at the source code level is:
    (a) New_H copies its input, thus takes one param.
    (b) New_H has an infinite loop at its accept state. >>>>>>>>>>>>>
    So, how is New_H a halt decider then?

    typo
    The only difference at the source code level is:
    (a) New_D copies its input, thus takes one param.
    (b) New_D has an infinite loop at its accept state.
    Other than that (at the source-code level) New_D is exactly >>>>>>>>>>>> New_H



    But New_D needs to call New_H,

    Not in the Peter Linz proof:
    https://www.liarparadox.org/Linz_Proof.pdf

    In the Linz proof a copy of H is directly embedded
    within Ĥ at this state: Ĥq0 Wm Wm
    The original H remains unchanged.

    The halting problem is about undecidable inputs, it is not about >>>>>>>>>> inserting bugs into a halt decider to make it cease to function. >>>>>>>>>>


    Right, and in Linz, H is the decider that is claimed to give >>>>>>>>> the right answer.

    That isn't 'H' in your system, but the script that decides
    whether to use H or H1.

    Your error is in calling the wrong thing 'H'

    You are just showing you are lying by using the wrong name for >>>>>>>>> things.

    You are using double-talk in a lame attempt to show that
    Linz H cannot correctly determine the halt status of Linz Ĥ.


    So you agree with the Theorem.

    No 'Linz H' can exist that correctly decides the halt status of
    Linz Ĥ applied to the description of Linz Ĥ.

    That is EXACTLY the consequence of the Halting Theorem.


    Please show an ACTUAL 'Linz H' that correctly gets the results of >>>>>>> the 'Linz Ĥ' built on it. You keep on changing H and trying to
    use the old Ĥ which just fails to meet the requirement of the
    proof, likely because you just don't understand the theory involved. >>>>>>
    It took me two years to figure out a clean way to copy the input to >>>>>> Linz_H_Hat and not have the system crash. Relative to Linz_H_Hat
    Linz_H is H1. Now Linz_H_Hat only contradicts itself.


    So, you are admitting that you actually can't do what is required?

    Copying the input should be trivial,

    The relative addressing of the x86 language causes all function
    calls to call the wrong address.

    Only because you aren't interpreting the input properly, but in a
    non-Turing Complete manner.

    As I said, the input description should be a chunck of code in a
    virtual address space with a header that tells where that code is
    supposed to be considered to be located at.


    as the input should be a representation that packages a full
    program in its own virtual environment, so a simple bit by bit copy
    to empty ram will work. Your problem is that you don't put the
    input into its own virtual address space, so you have pathological
    interactions.

    Linz_H_Hat must be built on the exact code base that is deciding on
    it, in this case H, since you just said it isn't, your proof is
    invalid.


    Linz_Hat <is> Linz_H that takes one param  and copies it instead of
    two params and has an infinite loop at its accept state.

    So, Two things that are different are exactly the same?


    It exactly matches the Linz spec.

    You don't seem to understand what you are doing.

    Linz_H_Hat (not Linz_Hat) is a Turing Machine with a defined
    behavior. That behavior is a function of its input, but hasn't been
    assigned any "meaning".

    Linz_H is a Turing Machine (if it actually can exist) that has a
    defined meaning/requirement for its final states. Linz_H, to meet its
    requirements, MUST go to Qy if the input represents a Halting
    Computation, and MUST go to Qn if the input represents a non-halting
    computation.

    Since Linz_H has actual requirements, a claimed implementation of it
    can be checked to see if it actually meets the requirements, and
    perhaps we can determine if it is possible to meet them.


    Note, Linz_H_Hat CAN'T "Contradict" itself, as doesn't generate any
    truth values, only behavior. You are just showing that you don't
    understand the basics of the requirements, and seem to think that
    "close" is good enough for proofs.

    Linz_H_Hat(Linz_H_Hat) returns 0.

    Actually no. Linz_H_Hat(Linz_H_Hat) halts at state Qn, which has NO
    defined meaning for Linz_H_Hat as it isn't defined to be a decider.

    Linz_H and Linz_H_Hat are C functions.
    Linz:H and Linz:Ĥ are Turing machines.

    So, inventing new terminology without introduction, thus showing you are being intentionally deceptive.


    Linz_H and Linz:H are both directly embedded within a copy of
    Linz_H_Hat and Linz:Ĥ thus a return value of 0 or a transition
    to Ĥ.qn still means not halting.

    No, because Linz_H_Hat / Linz:Ĥ are not "Halt Deciders" so there return value has no meaning.

    Ĥ has no meaning, so it can't be "incorrect" or contradicted.


    This allows Linz_H and Linz:H correctly report on the actual
    behavior of their input.



    No, since BOTH have an input that when run will HALT, and both report
    that it will not, both are just wrong.

    Linz_H(Linz_H_Hat, Linz_H_Hat) is claimed to "correctly" return 0,
    *I never said that you are confused*
    Linz_H_Hat(Linz_H_Hat) returns 0 permitting
    Linz_H(Linz_H_Hat, Linz_H_Hat) to correctly return 1.

    --
    Copyright 2023 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 Mon Jul 3 17:31:27 2023
    XPost: comp.theory, sci.logic

    On 7/3/23 5:19 PM, olcott wrote:
    On 7/3/2023 4:07 PM, Richard Damon wrote:
    On 7/3/23 4:45 PM, olcott wrote:
    On 7/3/2023 2:58 PM, Richard Damon wrote:
    On 7/3/23 2:56 PM, olcott wrote:
    On 7/3/2023 1:25 PM, Richard Damon wrote:
    On 7/3/23 2:03 PM, olcott wrote:
    On 7/3/2023 11:26 AM, Richard Damon wrote:
    On 7/3/23 12:05 PM, olcott wrote:
    On 7/3/2023 10:58 AM, Richard Damon wrote:
    On 7/3/23 11:44 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 10:42 AM, olcott wrote:
    On 7/3/2023 8:13 AM, Richard Damon wrote:
    On 7/2/23 11:10 PM, olcott wrote:

    Only when I show you are wrong. Actually try to answer my >>>>>>>>>>>>>> objections


    What about a three valued decider?
    0=undecidable
    1=halting
    2=not halting


    Doesn't meet the definition of a Halt Decider.


    Because these are semantic properties based on the behavior of >>>>>>>>>>> the input it does refute Rice.

    Nope. Rice's theorem doesn't allow for an 'undecidable' output >>>>>>>>>> state either.

    Either the input is or is not something that is in the set >>>>>>>>>> defined by the function/language defined.

    Undecidable is just admitting that Rice is true.


    Undecidable <is> a semantic property.

    Source of that Claim?

    And you aren't saying the Undecidable <IS> a semantic property, >>>>>>>> but is an answer for if an input <HAS> some specific semantic
    property.

    In computability theory, Rice's theorem states that all non-trivial >>>>>>> semantic properties of programs are undecidable. A semantic
    property is
    one about the program's behavior
    https://en.wikipedia.org/wiki/Rice%27s_theorem

    Undecidable <is> a semantic property of the finite string pair:
    {H,D}.


    As I mentioned, many simple descriptions get it wrong. Note, later >>>>>> in the same page it says:

    It is important to note that Rice's theorem does not concern the
    properties of machines or programs; it concerns properties of
    functions and languages.


    H correctly accepts every language specified by the pair: {H, *}
    (where the first element is the machine description of H and the
    second element is any other machine description) or rejects this
    pair as undecidable.



    So, you are admitting you don't understand what you are saying.

    D isn't "undecidable" but always has definite behavior based on the
    behavior of the definite machine H that it was based on (and thus
    you are being INTENTIONALLY dupicious by now calling H to be a some
    sort of other decider).

    Since you claim that Halt-Decider-H "Correctly" returned false for
    H(D,D) we know that D(D) Halts, so D the problem of D has an answer
    so hard to call "undecidable"

    Again, what is the definition of your "Language", and why do you
    call {H,D} as UNDECIDABLE, since H will be a FIXED DEFINED decider
    that is just WRONG about its input, that isn't "undecidable".


    Using Rogers' characterization of acceptable programming systems, Rice's >>> theorem may essentially be generalized from Turing machines to most
    computer programming languages: there exists no automatic method that
    decides with generality non-trivial questions on the behavior of
    computer programs. https://en.wikipedia.org/wiki/Rice%27s_theorem

    H correctly divides inputs into
    (a) Halting
    (b) Not halting
    (c) Cannot be decided by H


    And where do you see anything that allows H to be "correct" in giving
    answer (c)?

    The specific input either represents a machine that does (a) or does
    (b), so in no case is the results of "it can not be decided" be correct.

    You are just showing that you fundamentally don't understand what you
    are talking about.

    The question follows the rule of the excluded middle, so there is no
    valid answer (c).

    H is a correct halting decidability decider for itself.
    Rice says that is impossible, thus Rice is wrong.


    What you do mean by a "Decidability Decider"? As I have pointed out, Decidability isn't a property of an input, but of a whole problem.


    And How is it a "correct" decider when it gives the wrong answer to the
    problem about D(D)?

    This is NOT a "Undecidable" question, it has a correct answer, H is just
    wrong about it.

    You are just proving you don't understand the meaning of CORRECT and
    INCORRECT.

    You just don't know enough of what Rice is talking about to see how
    stupid your comments are.

    A perfect example of the Dunning-Kruger effect.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Richard Damon on Mon Jul 3 16:30:46 2023
    XPost: comp.theory, sci.logic

    On 7/3/2023 4:07 PM, Richard Damon wrote:
    On 7/3/23 4:08 PM, olcott wrote:
    On 7/3/2023 2:58 PM, Richard Damon wrote:
    On 7/3/23 2:56 PM, olcott wrote:
    On 7/3/2023 1:25 PM, Richard Damon wrote:
    On 7/3/23 2:03 PM, olcott wrote:
    On 7/3/2023 11:26 AM, Richard Damon wrote:
    On 7/3/23 12:05 PM, olcott wrote:
    On 7/3/2023 10:58 AM, Richard Damon wrote:
    On 7/3/23 11:44 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 10:42 AM, olcott wrote:
    On 7/3/2023 8:13 AM, Richard Damon wrote:
    On 7/2/23 11:10 PM, olcott wrote:

    Only when I show you are wrong. Actually try to answer my >>>>>>>>>>>>> objections


    What about a three valued decider?
    0=undecidable
    1=halting
    2=not halting


    Doesn't meet the definition of a Halt Decider.


    Because these are semantic properties based on the behavior of >>>>>>>>>> the input it does refute Rice.

    Nope. Rice's theorem doesn't allow for an 'undecidable' output >>>>>>>>> state either.

    Either the input is or is not something that is in the set
    defined by the function/language defined.

    Undecidable is just admitting that Rice is true.


    Undecidable <is> a semantic property.

    Source of that Claim?

    And you aren't saying the Undecidable <IS> a semantic property,
    but is an answer for if an input <HAS> some specific semantic
    property.

    In computability theory, Rice's theorem states that all non-trivial >>>>>> semantic properties of programs are undecidable. A semantic
    property is
    one about the program's behavior
    https://en.wikipedia.org/wiki/Rice%27s_theorem

    Undecidable <is> a semantic property of the finite string pair:
    {H,D}.


    As I mentioned, many simple descriptions get it wrong. Note, later
    in the same page it says:

    It is important to note that Rice's theorem does not concern the
    properties of machines or programs; it concerns properties of
    functions and languages.


    H correctly accepts every language specified by the pair: {H, *}
    (where the first element is the machine description of H and the
    second element is any other machine description) or rejects this
    pair as undecidable.



    So, you are admitting you don't understand what you are saying.

    D isn't "undecidable" but always has definite behavior based on the
    behavior of the definite machine H that it was based on (and thus you
    are being INTENTIONALLY dupicious by now calling H to be a some sort
    of other decider).

    Since you claim that Halt-Decider-H "Correctly" returned false for
    H(D,D) we know that D(D) Halts, so D the problem of D has an answer
    so hard to call "undecidable"

    Again, what is the definition of your "Language", and why do you call
    {H,D} as UNDECIDABLE, since H will be a FIXED DEFINED decider that is
    just WRONG about its input, that isn't "undecidable".

    {H,D} undecidable means that D is undecidable for H, which is an
    verified fact. The set of {H,*} finite string pairs do define a
    language.  Decidability <is> a semantic property because it
    can only be correctly decided on the basis of behavior.


    What do you mean by "Undecidable by H?"


    H correctly determines that it cannot provide a halt status
    consistent with the behavior of the directly executed D(D).

    H is a decidability decider for itself, thus determining the
    semantic property of finite string pairs: {H,*}.
    0==Undecidable
    1==Decidable
    2==Decidable


    --
    Copyright 2023 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 olcott@21:1/5 to Richard Damon on Mon Jul 3 16:36:49 2023
    XPost: comp.theory, sci.logic

    On 7/3/2023 4:31 PM, Richard Damon wrote:
    On 7/3/23 5:19 PM, olcott wrote:
    On 7/3/2023 4:07 PM, Richard Damon wrote:
    On 7/3/23 4:45 PM, olcott wrote:
    On 7/3/2023 2:58 PM, Richard Damon wrote:
    On 7/3/23 2:56 PM, olcott wrote:
    On 7/3/2023 1:25 PM, Richard Damon wrote:
    On 7/3/23 2:03 PM, olcott wrote:
    On 7/3/2023 11:26 AM, Richard Damon wrote:
    On 7/3/23 12:05 PM, olcott wrote:
    On 7/3/2023 10:58 AM, Richard Damon wrote:
    On 7/3/23 11:44 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 10:42 AM, olcott wrote:
    On 7/3/2023 8:13 AM, Richard Damon wrote:
    On 7/2/23 11:10 PM, olcott wrote:

    Only when I show you are wrong. Actually try to answer my >>>>>>>>>>>>>>> objections


    What about a three valued decider?
    0=undecidable
    1=halting
    2=not halting


    Doesn't meet the definition of a Halt Decider.


    Because these are semantic properties based on the behavior of >>>>>>>>>>>> the input it does refute Rice.

    Nope. Rice's theorem doesn't allow for an 'undecidable'
    output state either.

    Either the input is or is not something that is in the set >>>>>>>>>>> defined by the function/language defined.

    Undecidable is just admitting that Rice is true.


    Undecidable <is> a semantic property.

    Source of that Claim?

    And you aren't saying the Undecidable <IS> a semantic property, >>>>>>>>> but is an answer for if an input <HAS> some specific semantic >>>>>>>>> property.

    In computability theory, Rice's theorem states that all non-trivial >>>>>>>> semantic properties of programs are undecidable. A semantic
    property is
    one about the program's behavior
    https://en.wikipedia.org/wiki/Rice%27s_theorem

    Undecidable <is> a semantic property of the finite string pair: >>>>>>>> {H,D}.


    As I mentioned, many simple descriptions get it wrong. Note,
    later in the same page it says:

    It is important to note that Rice's theorem does not concern the >>>>>>> properties of machines or programs; it concerns properties of
    functions and languages.


    H correctly accepts every language specified by the pair: {H, *}
    (where the first element is the machine description of H and the
    second element is any other machine description) or rejects this
    pair as undecidable.



    So, you are admitting you don't understand what you are saying.

    D isn't "undecidable" but always has definite behavior based on the
    behavior of the definite machine H that it was based on (and thus
    you are being INTENTIONALLY dupicious by now calling H to be a some
    sort of other decider).

    Since you claim that Halt-Decider-H "Correctly" returned false for
    H(D,D) we know that D(D) Halts, so D the problem of D has an answer
    so hard to call "undecidable"

    Again, what is the definition of your "Language", and why do you
    call {H,D} as UNDECIDABLE, since H will be a FIXED DEFINED decider
    that is just WRONG about its input, that isn't "undecidable".


    Using Rogers' characterization of acceptable programming systems,
    Rice's
    theorem may essentially be generalized from Turing machines to most
    computer programming languages: there exists no automatic method that
    decides with generality non-trivial questions on the behavior of
    computer programs. https://en.wikipedia.org/wiki/Rice%27s_theorem

    H correctly divides inputs into
    (a) Halting
    (b) Not halting
    (c) Cannot be decided by H


    And where do you see anything that allows H to be "correct" in giving
    answer (c)?

    The specific input either represents a machine that does (a) or does
    (b), so in no case is the results of "it can not be decided" be correct. >>>
    You are just showing that you fundamentally don't understand what you
    are talking about.

    The question follows the rule of the excluded middle, so there is no
    valid answer (c).

    H is a correct halting decidability decider for itself.
    Rice says that is impossible, thus Rice is wrong.


    What you do mean by a "Decidability Decider"? As I have pointed out, Decidability isn't a property of an input, but of a whole problem.

    H correctly divides finite string pairs {H,*} into decidable by H and undecidable by H, a semantic property of these finite string pairs.

    --
    Copyright 2023 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 Mon Jul 3 17:55:42 2023
    XPost: comp.theory, sci.logic

    On 7/3/23 5:34 PM, olcott wrote:
    On 7/3/2023 4:17 PM, Richard Damon wrote:
    On 7/3/23 4:22 PM, olcott wrote:
    On 7/3/2023 2:58 PM, Richard Damon wrote:
    On 7/3/23 2:48 PM, olcott wrote:
    On 7/3/2023 1:25 PM, Richard Damon wrote:
    On 7/3/23 1:57 PM, olcott wrote:
    On 7/3/2023 11:26 AM, Richard Damon wrote:
    On 7/3/23 12:11 PM, olcott wrote:
    On 7/3/2023 11:01 AM, Richard Damon wrote:
    On 7/3/23 11:56 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 10:45 AM, olcott wrote:
    On 7/3/2023 9:24 AM, Richard Damon wrote:
    On 7/3/23 9:47 AM, olcott wrote:
    On 7/3/2023 8:14 AM, Richard Damon wrote:
    On 7/2/23 10:48 PM, olcott wrote:
    On 7/2/2023 9:41 PM, Richard Damon wrote:
    On 7/2/23 10:01 PM, olcott wrote:
    On 7/2/2023 8:40 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 7/2/23 8:45 PM, olcott wrote:
    A single H can consistently correctly determine >>>>>>>>>>>>>>>>>>>>> whether or not its input
    is pathological relative to itself. When H(D,D) is >>>>>>>>>>>>>>>>>>>>> invoked in
    decidability decider mode determines that D is >>>>>>>>>>>>>>>>>>>>> pathological relative to
    itself this enables a batch file to invoke H1(D,D) >>>>>>>>>>>>>>>>>>>>> to get the actual
    behavior of the directly executed D(D). H1 is >>>>>>>>>>>>>>>>>>>>> identical to H except for
    the pathological relationship to H.



    And does an input D that uses this FULL algorithm >>>>>>>>>>>>>>>>>>>> give your algorithm problems?

    Since H(D,D) will (apparently) determine that the >>>>>>>>>>>>>>>>>>>> input is pathological, and thus defer to H1(D,D), >>>>>>>>>>>>>>>>>>>> then when we actually run D, appearently it will get >>>>>>>>>>>>>>>>>>>> that same answer from H1 and do the opposite of it, >>>>>>>>>>>>>>>>>>>> and thus H1 will be wrong.

    Remember, the "Pathological" program is built on a >>>>>>>>>>>>>>>>>>>> copy of the ACTUAL program that you ask to decide on >>>>>>>>>>>>>>>>>>>> it, including ALL of its "tricks", including things >>>>>>>>>>>>>>>>>>>> like this "batch processing".

    You seem to be assuming that there is some >>>>>>>>>>>>>>>>>>>> "Operationg System" outside the Decider - Input >>>>>>>>>>>>>>>>>>>> structure, but there isn't, at least not one that >>>>>>>>>>>>>>>>>>>> can affect the answer of the problem.

    I spent 12 hours a day for the last 10 days getting >>>>>>>>>>>>>>>>>>> the copy the input
    working. When H(D,D) (in decidability decider mode) >>>>>>>>>>>>>>>>>>> detects that its
    input is in the well defined set of pathological >>>>>>>>>>>>>>>>>>> inputs it returns 0
    indicating that its input is undecidable. The batch >>>>>>>>>>>>>>>>>>> file that invoked H
    then knows to invoke H1(D,D) to correctly report that >>>>>>>>>>>>>>>>>>> D(D) halts.

    This solution does seem to work correctly on every >>>>>>>>>>>>>>>>>>> conventional proof in
    every textbook.


    So, did you make your "conventional proof" template >>>>>>>>>>>>>>>>>> actually use a copy of your ACTUAL decider (which >>>>>>>>>>>>>>>>>> seems to be your "batch file" not the C funciton H), >>>>>>>>>>>>>>>>>> or are you just admitting that you wasted 120 hours >>>>>>>>>>>>>>>>>> looking at the wrong thing because you have made >>>>>>>>>>>>>>>>>> yourself intentionally ignorant of the subject so you >>>>>>>>>>>>>>>>>> don't understand what you are trying to do. >>>>>>>>>>>>>>>>>
    New_D copies its input and simulates its input with its >>>>>>>>>>>>>>>>> input.
    It never sees New_H.


    Why not? Since New_H is the thing that is considered the >>>>>>>>>>>>>>>> "Correct Halt Decider", New_D needs to be built on it. >>>>>>>>>>>>>>>>

    New_H is embedded within New_D (as its middle states) >>>>>>>>>>>>>>> just the
    way it is supposed to be. The question is: Does
    New_H(New_H) halt?

    The only difference at the source code level is: >>>>>>>>>>>>>>> (a) New_H copies its input, thus takes one param. >>>>>>>>>>>>>>> (b) New_H has an infinite loop at its accept state. >>>>>>>>>>>>>>
    So, how is New_H a halt decider then?

    typo
    The only difference at the source code level is:
    (a) New_D copies its input, thus takes one param.
    (b) New_D has an infinite loop at its accept state.
    Other than that (at the source-code level) New_D is exactly >>>>>>>>>>>>> New_H



    But New_D needs to call New_H,

    Not in the Peter Linz proof:
    https://www.liarparadox.org/Linz_Proof.pdf

    In the Linz proof a copy of H is directly embedded
    within Ĥ at this state: Ĥq0 Wm Wm
    The original H remains unchanged.

    The halting problem is about undecidable inputs, it is not about >>>>>>>>>>> inserting bugs into a halt decider to make it cease to function. >>>>>>>>>>>


    Right, and in Linz, H is the decider that is claimed to give >>>>>>>>>> the right answer.

    That isn't 'H' in your system, but the script that decides >>>>>>>>>> whether to use H or H1.

    Your error is in calling the wrong thing 'H'

    You are just showing you are lying by using the wrong name for >>>>>>>>>> things.

    You are using double-talk in a lame attempt to show that
    Linz H cannot correctly determine the halt status of Linz Ĥ. >>>>>>>>>

    So you agree with the Theorem.

    No 'Linz H' can exist that correctly decides the halt status of >>>>>>>> Linz Ĥ applied to the description of Linz Ĥ.

    That is EXACTLY the consequence of the Halting Theorem.


    Please show an ACTUAL 'Linz H' that correctly gets the results >>>>>>>> of the 'Linz Ĥ' built on it. You keep on changing H and trying >>>>>>>> to use the old Ĥ which just fails to meet the requirement of the >>>>>>>> proof, likely because you just don't understand the theory
    involved.

    It took me two years to figure out a clean way to copy the input to >>>>>>> Linz_H_Hat and not have the system crash. Relative to Linz_H_Hat >>>>>>> Linz_H is H1. Now Linz_H_Hat only contradicts itself.


    So, you are admitting that you actually can't do what is required? >>>>>>
    Copying the input should be trivial,

    The relative addressing of the x86 language causes all function
    calls to call the wrong address.

    Only because you aren't interpreting the input properly, but in a
    non-Turing Complete manner.

    As I said, the input description should be a chunck of code in a
    virtual address space with a header that tells where that code is
    supposed to be considered to be located at.


    as the input should be a representation that packages a full
    program in its own virtual environment, so a simple bit by bit
    copy to empty ram will work. Your problem is that you don't put
    the input into its own virtual address space, so you have
    pathological interactions.

    Linz_H_Hat must be built on the exact code base that is deciding
    on it, in this case H, since you just said it isn't, your proof is >>>>>> invalid.


    Linz_Hat <is> Linz_H that takes one param  and copies it instead of >>>>> two params and has an infinite loop at its accept state.

    So, Two things that are different are exactly the same?


    It exactly matches the Linz spec.

    You don't seem to understand what you are doing.

    Linz_H_Hat (not Linz_Hat) is a Turing Machine with a defined
    behavior. That behavior is a function of its input, but hasn't been
    assigned any "meaning".

    Linz_H is a Turing Machine (if it actually can exist) that has a
    defined meaning/requirement for its final states. Linz_H, to meet
    its requirements, MUST go to Qy if the input represents a Halting
    Computation, and MUST go to Qn if the input represents a non-halting
    computation.

    Since Linz_H has actual requirements, a claimed implementation of it
    can be checked to see if it actually meets the requirements, and
    perhaps we can determine if it is possible to meet them.


    Note, Linz_H_Hat CAN'T "Contradict" itself, as doesn't generate
    any truth values, only behavior. You are just showing that you
    don't understand the basics of the requirements, and seem to think >>>>>> that "close" is good enough for proofs.

    Linz_H_Hat(Linz_H_Hat) returns 0.

    Actually no. Linz_H_Hat(Linz_H_Hat) halts at state Qn, which has NO
    defined meaning for Linz_H_Hat as it isn't defined to be a decider.

    Linz_H and Linz_H_Hat are C functions.
    Linz:H and Linz:Ĥ are Turing machines.

    So, inventing new terminology without introduction, thus showing you
    are being intentionally deceptive.


    Linz_H and Linz:H are both directly embedded within a copy of
    Linz_H_Hat and Linz:Ĥ thus a return value of 0 or a transition
    to Ĥ.qn still means not halting.

    No, because Linz_H_Hat / Linz:Ĥ are not "Halt Deciders" so there
    return value has no meaning.

    Ĥ has no meaning, so it can't be "incorrect" or contradicted.


    This allows Linz_H and Linz:H correctly report on the actual
    behavior of their input.



    No, since BOTH have an input that when run will HALT, and both report
    that it will not, both are just wrong.

    Linz_H(Linz_H_Hat, Linz_H_Hat) is claimed to "correctly" return 0,
    *I never said that you are confused*

    You always claim that your H by its various names is "Correct" to return
    0 as the input is non-halting because its "correct simulation" will
    never reach a final state.

    I think your brain is turning into mush, or is your pathology
    overloading and trying to reverse the argument.

    Linz_H_Hat(Linz_H_Hat) returns 0 permitting
    Linz_H(Linz_H_Hat, Linz_H_Hat) to correctly return 1.


    But if Linz_H(Linz_H_Hat, Linz_H_Hat) returns 1, which means Halting, it
    means that Linz_H_Hat will go into the infinte loop on the Qy leg.

    Did you miss that parto of the design in Linz's proof. H^ has modified
    the end of H so that Qy becomes a non-terminal state.

    Linz_H_Hat doesn't actually "return" a value, it just goes to Qn and
    halt or never halts.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Richard Damon on Mon Jul 3 21:28:18 2023
    XPost: comp.theory, sci.logic

    On 7/3/2023 4:55 PM, Richard Damon wrote:
    On 7/3/23 5:36 PM, olcott wrote:
    On 7/3/2023 4:31 PM, Richard Damon wrote:
    On 7/3/23 5:19 PM, olcott wrote:
    On 7/3/2023 4:07 PM, Richard Damon wrote:
    On 7/3/23 4:45 PM, olcott wrote:
    On 7/3/2023 2:58 PM, Richard Damon wrote:
    On 7/3/23 2:56 PM, olcott wrote:
    On 7/3/2023 1:25 PM, Richard Damon wrote:
    On 7/3/23 2:03 PM, olcott wrote:
    On 7/3/2023 11:26 AM, Richard Damon wrote:
    On 7/3/23 12:05 PM, olcott wrote:
    On 7/3/2023 10:58 AM, Richard Damon wrote:
    On 7/3/23 11:44 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 10:42 AM, olcott wrote:
    On 7/3/2023 8:13 AM, Richard Damon wrote:
    On 7/2/23 11:10 PM, olcott wrote:

    Only when I show you are wrong. Actually try to answer >>>>>>>>>>>>>>>>> my objections


    What about a three valued decider?
    0=undecidable
    1=halting
    2=not halting


    Doesn't meet the definition of a Halt Decider.


    Because these are semantic properties based on the >>>>>>>>>>>>>> behavior of
    the input it does refute Rice.

    Nope. Rice's theorem doesn't allow for an 'undecidable' >>>>>>>>>>>>> output state either.

    Either the input is or is not something that is in the set >>>>>>>>>>>>> defined by the function/language defined.

    Undecidable is just admitting that Rice is true.


    Undecidable <is> a semantic property.

    Source of that Claim?

    And you aren't saying the Undecidable <IS> a semantic
    property, but is an answer for if an input <HAS> some
    specific semantic property.

    In computability theory, Rice's theorem states that all
    non-trivial
    semantic properties of programs are undecidable. A semantic >>>>>>>>>> property is
    one about the program's behavior
    https://en.wikipedia.org/wiki/Rice%27s_theorem

    Undecidable <is> a semantic property of the finite string
    pair: {H,D}.


    As I mentioned, many simple descriptions get it wrong. Note, >>>>>>>>> later in the same page it says:

    It is important to note that Rice's theorem does not concern >>>>>>>>> the properties of machines or programs; it concerns properties >>>>>>>>> of functions and languages.


    H correctly accepts every language specified by the pair: {H, *} >>>>>>>> (where the first element is the machine description of H and the >>>>>>>> second element is any other machine description) or rejects this >>>>>>>> pair as undecidable.



    So, you are admitting you don't understand what you are saying.

    D isn't "undecidable" but always has definite behavior based on
    the behavior of the definite machine H that it was based on (and >>>>>>> thus you are being INTENTIONALLY dupicious by now calling H to be >>>>>>> a some sort of other decider).

    Since you claim that Halt-Decider-H "Correctly" returned false
    for H(D,D) we know that D(D) Halts, so D the problem of D has an >>>>>>> answer so hard to call "undecidable"

    Again, what is the definition of your "Language", and why do you >>>>>>> call {H,D} as UNDECIDABLE, since H will be a FIXED DEFINED
    decider that is just WRONG about its input, that isn't
    "undecidable".


    Using Rogers' characterization of acceptable programming systems,
    Rice's
    theorem may essentially be generalized from Turing machines to most >>>>>> computer programming languages: there exists no automatic method that >>>>>> decides with generality non-trivial questions on the behavior of
    computer programs. https://en.wikipedia.org/wiki/Rice%27s_theorem

    H correctly divides inputs into
    (a) Halting
    (b) Not halting
    (c) Cannot be decided by H


    And where do you see anything that allows H to be "correct" in
    giving answer (c)?

    The specific input either represents a machine that does (a) or
    does (b), so in no case is the results of "it can not be decided"
    be correct.

    You are just showing that you fundamentally don't understand what
    you are talking about.

    The question follows the rule of the excluded middle, so there is
    no valid answer (c).

    H is a correct halting decidability decider for itself.
    Rice says that is impossible, thus Rice is wrong.


    What you do mean by a "Decidability Decider"? As I have pointed out,
    Decidability isn't a property of an input, but of a whole problem.

    H correctly divides finite string pairs {H,*} into decidable by H and
    undecidable by H, a semantic property of these finite string pairs.


    No such property. Inputs are not "Decidable", problems are.

    I didn't say that quite right. H is a halting decidability decider.
    That really seems to be a semantic property of finite strings.


    You are just showing your stupidity.


    Neither one of us are anywhere near stupid, yet calling me
    stupid makes you look very immature and unprofessional.

    And that you just don't know what Truth means, as you are just a
    pathological liar.

    --
    Copyright 2023 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 olcott@21:1/5 to Richard Damon on Mon Jul 3 21:20:45 2023
    XPost: comp.theory, sci.logic

    On 7/3/2023 4:55 PM, Richard Damon wrote:
    On 7/3/23 5:34 PM, olcott wrote:
    On 7/3/2023 4:17 PM, Richard Damon wrote:
    On 7/3/23 4:22 PM, olcott wrote:
    On 7/3/2023 2:58 PM, Richard Damon wrote:
    On 7/3/23 2:48 PM, olcott wrote:
    On 7/3/2023 1:25 PM, Richard Damon wrote:
    On 7/3/23 1:57 PM, olcott wrote:
    On 7/3/2023 11:26 AM, Richard Damon wrote:
    On 7/3/23 12:11 PM, olcott wrote:
    On 7/3/2023 11:01 AM, Richard Damon wrote:
    On 7/3/23 11:56 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 10:45 AM, olcott wrote:
    On 7/3/2023 9:24 AM, Richard Damon wrote:
    On 7/3/23 9:47 AM, olcott wrote:
    On 7/3/2023 8:14 AM, Richard Damon wrote:
    On 7/2/23 10:48 PM, olcott wrote:
    On 7/2/2023 9:41 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>> On 7/2/23 10:01 PM, olcott wrote:
    On 7/2/2023 8:40 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>> On 7/2/23 8:45 PM, olcott wrote:
    A single H can consistently correctly determine >>>>>>>>>>>>>>>>>>>>>> whether or not its input
    is pathological relative to itself. When H(D,D) is >>>>>>>>>>>>>>>>>>>>>> invoked in
    decidability decider mode determines that D is >>>>>>>>>>>>>>>>>>>>>> pathological relative to
    itself this enables a batch file to invoke H1(D,D) >>>>>>>>>>>>>>>>>>>>>> to get the actual
    behavior of the directly executed D(D). H1 is >>>>>>>>>>>>>>>>>>>>>> identical to H except for
    the pathological relationship to H. >>>>>>>>>>>>>>>>>>>>>>


    And does an input D that uses this FULL algorithm >>>>>>>>>>>>>>>>>>>>> give your algorithm problems?

    Since H(D,D) will (apparently) determine that the >>>>>>>>>>>>>>>>>>>>> input is pathological, and thus defer to H1(D,D), >>>>>>>>>>>>>>>>>>>>> then when we actually run D, appearently it will >>>>>>>>>>>>>>>>>>>>> get that same answer from H1 and do the opposite of >>>>>>>>>>>>>>>>>>>>> it, and thus H1 will be wrong.

    Remember, the "Pathological" program is built on a >>>>>>>>>>>>>>>>>>>>> copy of the ACTUAL program that you ask to decide >>>>>>>>>>>>>>>>>>>>> on it, including ALL of its "tricks", including >>>>>>>>>>>>>>>>>>>>> things like this "batch processing". >>>>>>>>>>>>>>>>>>>>>
    You seem to be assuming that there is some >>>>>>>>>>>>>>>>>>>>> "Operationg System" outside the Decider - Input >>>>>>>>>>>>>>>>>>>>> structure, but there isn't, at least not one that >>>>>>>>>>>>>>>>>>>>> can affect the answer of the problem. >>>>>>>>>>>>>>>>>>>>
    I spent 12 hours a day for the last 10 days getting >>>>>>>>>>>>>>>>>>>> the copy the input
    working. When H(D,D) (in decidability decider mode) >>>>>>>>>>>>>>>>>>>> detects that its
    input is in the well defined set of pathological >>>>>>>>>>>>>>>>>>>> inputs it returns 0
    indicating that its input is undecidable. The batch >>>>>>>>>>>>>>>>>>>> file that invoked H
    then knows to invoke H1(D,D) to correctly report >>>>>>>>>>>>>>>>>>>> that D(D) halts.

    This solution does seem to work correctly on every >>>>>>>>>>>>>>>>>>>> conventional proof in
    every textbook.


    So, did you make your "conventional proof" template >>>>>>>>>>>>>>>>>>> actually use a copy of your ACTUAL decider (which >>>>>>>>>>>>>>>>>>> seems to be your "batch file" not the C funciton H), >>>>>>>>>>>>>>>>>>> or are you just admitting that you wasted 120 hours >>>>>>>>>>>>>>>>>>> looking at the wrong thing because you have made >>>>>>>>>>>>>>>>>>> yourself intentionally ignorant of the subject so you >>>>>>>>>>>>>>>>>>> don't understand what you are trying to do. >>>>>>>>>>>>>>>>>>
    New_D copies its input and simulates its input with >>>>>>>>>>>>>>>>>> its input.
    It never sees New_H.


    Why not? Since New_H is the thing that is considered >>>>>>>>>>>>>>>>> the "Correct Halt Decider", New_D needs to be built on it. >>>>>>>>>>>>>>>>>

    New_H is embedded within New_D (as its middle states) >>>>>>>>>>>>>>>> just the
    way it is supposed to be. The question is: Does >>>>>>>>>>>>>>>> New_H(New_H) halt?

    The only difference at the source code level is: >>>>>>>>>>>>>>>> (a) New_H copies its input, thus takes one param. >>>>>>>>>>>>>>>> (b) New_H has an infinite loop at its accept state. >>>>>>>>>>>>>>>
    So, how is New_H a halt decider then?

    typo
    The only difference at the source code level is:
    (a) New_D copies its input, thus takes one param.
    (b) New_D has an infinite loop at its accept state. >>>>>>>>>>>>>> Other than that (at the source-code level) New_D is >>>>>>>>>>>>>> exactly New_H



    But New_D needs to call New_H,

    Not in the Peter Linz proof:
    https://www.liarparadox.org/Linz_Proof.pdf

    In the Linz proof a copy of H is directly embedded
    within Ĥ at this state: Ĥq0 Wm Wm
    The original H remains unchanged.

    The halting problem is about undecidable inputs, it is not >>>>>>>>>>>> about
    inserting bugs into a halt decider to make it cease to >>>>>>>>>>>> function.



    Right, and in Linz, H is the decider that is claimed to give >>>>>>>>>>> the right answer.

    That isn't 'H' in your system, but the script that decides >>>>>>>>>>> whether to use H or H1.

    Your error is in calling the wrong thing 'H'

    You are just showing you are lying by using the wrong name >>>>>>>>>>> for things.

    You are using double-talk in a lame attempt to show that
    Linz H cannot correctly determine the halt status of Linz Ĥ. >>>>>>>>>>

    So you agree with the Theorem.

    No 'Linz H' can exist that correctly decides the halt status of >>>>>>>>> Linz Ĥ applied to the description of Linz Ĥ.

    That is EXACTLY the consequence of the Halting Theorem.


    Please show an ACTUAL 'Linz H' that correctly gets the results >>>>>>>>> of the 'Linz Ĥ' built on it. You keep on changing H and trying >>>>>>>>> to use the old Ĥ which just fails to meet the requirement of >>>>>>>>> the proof, likely because you just don't understand the theory >>>>>>>>> involved.

    It took me two years to figure out a clean way to copy the input to >>>>>>>> Linz_H_Hat and not have the system crash. Relative to Linz_H_Hat >>>>>>>> Linz_H is H1. Now Linz_H_Hat only contradicts itself.


    So, you are admitting that you actually can't do what is required? >>>>>>>
    Copying the input should be trivial,

    The relative addressing of the x86 language causes all function
    calls to call the wrong address.

    Only because you aren't interpreting the input properly, but in a
    non-Turing Complete manner.

    As I said, the input description should be a chunck of code in a
    virtual address space with a header that tells where that code is
    supposed to be considered to be located at.


    as the input should be a representation that packages a full
    program in its own virtual environment, so a simple bit by bit
    copy to empty ram will work. Your problem is that you don't put
    the input into its own virtual address space, so you have
    pathological interactions.

    Linz_H_Hat must be built on the exact code base that is deciding >>>>>>> on it, in this case H, since you just said it isn't, your proof
    is invalid.


    Linz_Hat <is> Linz_H that takes one param  and copies it instead of >>>>>> two params and has an infinite loop at its accept state.

    So, Two things that are different are exactly the same?


    It exactly matches the Linz spec.

    You don't seem to understand what you are doing.

    Linz_H_Hat (not Linz_Hat) is a Turing Machine with a defined
    behavior. That behavior is a function of its input, but hasn't been
    assigned any "meaning".

    Linz_H is a Turing Machine (if it actually can exist) that has a
    defined meaning/requirement for its final states. Linz_H, to meet
    its requirements, MUST go to Qy if the input represents a Halting
    Computation, and MUST go to Qn if the input represents a
    non-halting computation.

    Since Linz_H has actual requirements, a claimed implementation of
    it can be checked to see if it actually meets the requirements, and
    perhaps we can determine if it is possible to meet them.


    Note, Linz_H_Hat CAN'T "Contradict" itself, as doesn't generate
    any truth values, only behavior. You are just showing that you
    don't understand the basics of the requirements, and seem to
    think that "close" is good enough for proofs.

    Linz_H_Hat(Linz_H_Hat) returns 0.

    Actually no. Linz_H_Hat(Linz_H_Hat) halts at state Qn, which has NO >>>>> defined meaning for Linz_H_Hat as it isn't defined to be a decider.

    Linz_H and Linz_H_Hat are C functions.
    Linz:H and Linz:Ĥ are Turing machines.

    So, inventing new terminology without introduction, thus showing you
    are being intentionally deceptive.


    Linz_H and Linz:H are both directly embedded within a copy of
    Linz_H_Hat and Linz:Ĥ thus a return value of 0 or a transition
    to Ĥ.qn still means not halting.

    No, because Linz_H_Hat / Linz:Ĥ are not "Halt Deciders" so there
    return value has no meaning.

    Ĥ has no meaning, so it can't be "incorrect" or contradicted.


    This allows Linz_H and Linz:H correctly report on the actual
    behavior of their input.



    No, since BOTH have an input that when run will HALT, and both report
    that it will not, both are just wrong.

    Linz_H(Linz_H_Hat, Linz_H_Hat) is claimed to "correctly" return 0,
    *I never said that you are confused*

    You always claim that your H by its various names is "Correct" to return
    0 as the input is non-halting because its "correct simulation" will
    never reach a final state.

    I think your brain is turning into mush, or is your pathology
    overloading and trying to reverse the argument.

    Linz_H_Hat(Linz_H_Hat) returns 0 permitting
    Linz_H(Linz_H_Hat, Linz_H_Hat) to correctly return 1.


    But if Linz_H(Linz_H_Hat, Linz_H_Hat) returns 1, which means Halting,

    Linz_H_Hat has its own embedded_H that returns 0.
    Linz_H_Hat has no access to Linz_H, only to its own embedded copy.
    Linz_H simply simulates Linz_H_Hat until it terminates.

    it
    means that Linz_H_Hat will go into the infinte loop on the Qy leg.

    Did you miss that parto of the design in Linz's proof. H^ has modified
    the end of H so that Qy becomes a non-terminal state.

    Linz_H_Hat doesn't actually "return" a value, it just goes to Qn and

    Linz_H_Hat is a C function Linz:Ĥ is a Turing machine.
    They use the exact same algorithm.

    halt or never halts.


    --
    Copyright 2023 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 Mon Jul 3 23:22:03 2023
    XPost: comp.theory, sci.logic

    On 7/3/23 10:20 PM, olcott wrote:
    On 7/3/2023 4:55 PM, Richard Damon wrote:
    On 7/3/23 5:34 PM, olcott wrote:
    On 7/3/2023 4:17 PM, Richard Damon wrote:
    On 7/3/23 4:22 PM, olcott wrote:
    On 7/3/2023 2:58 PM, Richard Damon wrote:
    On 7/3/23 2:48 PM, olcott wrote:
    On 7/3/2023 1:25 PM, Richard Damon wrote:
    On 7/3/23 1:57 PM, olcott wrote:
    On 7/3/2023 11:26 AM, Richard Damon wrote:
    On 7/3/23 12:11 PM, olcott wrote:
    On 7/3/2023 11:01 AM, Richard Damon wrote:
    On 7/3/23 11:56 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 10:45 AM, olcott wrote:
    On 7/3/2023 9:24 AM, Richard Damon wrote:
    On 7/3/23 9:47 AM, olcott wrote:
    On 7/3/2023 8:14 AM, Richard Damon wrote:
    On 7/2/23 10:48 PM, olcott wrote:
    On 7/2/2023 9:41 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 7/2/23 10:01 PM, olcott wrote:
    On 7/2/2023 8:40 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>> On 7/2/23 8:45 PM, olcott wrote:
    A single H can consistently correctly determine >>>>>>>>>>>>>>>>>>>>>>> whether or not its input
    is pathological relative to itself. When H(D,D) >>>>>>>>>>>>>>>>>>>>>>> is invoked in
    decidability decider mode determines that D is >>>>>>>>>>>>>>>>>>>>>>> pathological relative to
    itself this enables a batch file to invoke >>>>>>>>>>>>>>>>>>>>>>> H1(D,D) to get the actual
    behavior of the directly executed D(D). H1 is >>>>>>>>>>>>>>>>>>>>>>> identical to H except for
    the pathological relationship to H. >>>>>>>>>>>>>>>>>>>>>>>


    And does an input D that uses this FULL algorithm >>>>>>>>>>>>>>>>>>>>>> give your algorithm problems?

    Since H(D,D) will (apparently) determine that the >>>>>>>>>>>>>>>>>>>>>> input is pathological, and thus defer to H1(D,D), >>>>>>>>>>>>>>>>>>>>>> then when we actually run D, appearently it will >>>>>>>>>>>>>>>>>>>>>> get that same answer from H1 and do the opposite >>>>>>>>>>>>>>>>>>>>>> of it, and thus H1 will be wrong.

    Remember, the "Pathological" program is built on a >>>>>>>>>>>>>>>>>>>>>> copy of the ACTUAL program that you ask to decide >>>>>>>>>>>>>>>>>>>>>> on it, including ALL of its "tricks", including >>>>>>>>>>>>>>>>>>>>>> things like this "batch processing". >>>>>>>>>>>>>>>>>>>>>>
    You seem to be assuming that there is some >>>>>>>>>>>>>>>>>>>>>> "Operationg System" outside the Decider - Input >>>>>>>>>>>>>>>>>>>>>> structure, but there isn't, at least not one that >>>>>>>>>>>>>>>>>>>>>> can affect the answer of the problem. >>>>>>>>>>>>>>>>>>>>>
    I spent 12 hours a day for the last 10 days getting >>>>>>>>>>>>>>>>>>>>> the copy the input
    working. When H(D,D) (in decidability decider mode) >>>>>>>>>>>>>>>>>>>>> detects that its
    input is in the well defined set of pathological >>>>>>>>>>>>>>>>>>>>> inputs it returns 0
    indicating that its input is undecidable. The batch >>>>>>>>>>>>>>>>>>>>> file that invoked H
    then knows to invoke H1(D,D) to correctly report >>>>>>>>>>>>>>>>>>>>> that D(D) halts.

    This solution does seem to work correctly on every >>>>>>>>>>>>>>>>>>>>> conventional proof in
    every textbook.


    So, did you make your "conventional proof" template >>>>>>>>>>>>>>>>>>>> actually use a copy of your ACTUAL decider (which >>>>>>>>>>>>>>>>>>>> seems to be your "batch file" not the C funciton H), >>>>>>>>>>>>>>>>>>>> or are you just admitting that you wasted 120 hours >>>>>>>>>>>>>>>>>>>> looking at the wrong thing because you have made >>>>>>>>>>>>>>>>>>>> yourself intentionally ignorant of the subject so >>>>>>>>>>>>>>>>>>>> you don't understand what you are trying to do. >>>>>>>>>>>>>>>>>>>
    New_D copies its input and simulates its input with >>>>>>>>>>>>>>>>>>> its input.
    It never sees New_H.


    Why not? Since New_H is the thing that is considered >>>>>>>>>>>>>>>>>> the "Correct Halt Decider", New_D needs to be built on >>>>>>>>>>>>>>>>>> it.


    New_H is embedded within New_D (as its middle states) >>>>>>>>>>>>>>>>> just the
    way it is supposed to be. The question is: Does >>>>>>>>>>>>>>>>> New_H(New_H) halt?

    The only difference at the source code level is: >>>>>>>>>>>>>>>>> (a) New_H copies its input, thus takes one param. >>>>>>>>>>>>>>>>> (b) New_H has an infinite loop at its accept state. >>>>>>>>>>>>>>>>
    So, how is New_H a halt decider then?

    typo
    The only difference at the source code level is: >>>>>>>>>>>>>>> (a) New_D copies its input, thus takes one param. >>>>>>>>>>>>>>> (b) New_D has an infinite loop at its accept state. >>>>>>>>>>>>>>> Other than that (at the source-code level) New_D is >>>>>>>>>>>>>>> exactly New_H



    But New_D needs to call New_H,

    Not in the Peter Linz proof:
    https://www.liarparadox.org/Linz_Proof.pdf

    In the Linz proof a copy of H is directly embedded
    within Ĥ at this state: Ĥq0 Wm Wm
    The original H remains unchanged.

    The halting problem is about undecidable inputs, it is not >>>>>>>>>>>>> about
    inserting bugs into a halt decider to make it cease to >>>>>>>>>>>>> function.



    Right, and in Linz, H is the decider that is claimed to give >>>>>>>>>>>> the right answer.

    That isn't 'H' in your system, but the script that decides >>>>>>>>>>>> whether to use H or H1.

    Your error is in calling the wrong thing 'H'

    You are just showing you are lying by using the wrong name >>>>>>>>>>>> for things.

    You are using double-talk in a lame attempt to show that >>>>>>>>>>> Linz H cannot correctly determine the halt status of Linz Ĥ. >>>>>>>>>>>

    So you agree with the Theorem.

    No 'Linz H' can exist that correctly decides the halt status >>>>>>>>>> of Linz Ĥ applied to the description of Linz Ĥ.

    That is EXACTLY the consequence of the Halting Theorem.


    Please show an ACTUAL 'Linz H' that correctly gets the results >>>>>>>>>> of the 'Linz Ĥ' built on it. You keep on changing H and trying >>>>>>>>>> to use the old Ĥ which just fails to meet the requirement of >>>>>>>>>> the proof, likely because you just don't understand the theory >>>>>>>>>> involved.

    It took me two years to figure out a clean way to copy the
    input to
    Linz_H_Hat and not have the system crash. Relative to Linz_H_Hat >>>>>>>>> Linz_H is H1. Now Linz_H_Hat only contradicts itself.


    So, you are admitting that you actually can't do what is required? >>>>>>>>
    Copying the input should be trivial,

    The relative addressing of the x86 language causes all function
    calls to call the wrong address.

    Only because you aren't interpreting the input properly, but in a
    non-Turing Complete manner.

    As I said, the input description should be a chunck of code in a
    virtual address space with a header that tells where that code is
    supposed to be considered to be located at.


    as the input should be a representation that packages a full
    program in its own virtual environment, so a simple bit by bit >>>>>>>> copy to empty ram will work. Your problem is that you don't put >>>>>>>> the input into its own virtual address space, so you have
    pathological interactions.

    Linz_H_Hat must be built on the exact code base that is deciding >>>>>>>> on it, in this case H, since you just said it isn't, your proof >>>>>>>> is invalid.


    Linz_Hat <is> Linz_H that takes one param  and copies it instead of >>>>>>> two params and has an infinite loop at its accept state.

    So, Two things that are different are exactly the same?


    It exactly matches the Linz spec.

    You don't seem to understand what you are doing.

    Linz_H_Hat (not Linz_Hat) is a Turing Machine with a defined
    behavior. That behavior is a function of its input, but hasn't
    been assigned any "meaning".

    Linz_H is a Turing Machine (if it actually can exist) that has a
    defined meaning/requirement for its final states. Linz_H, to meet
    its requirements, MUST go to Qy if the input represents a Halting
    Computation, and MUST go to Qn if the input represents a
    non-halting computation.

    Since Linz_H has actual requirements, a claimed implementation of
    it can be checked to see if it actually meets the requirements,
    and perhaps we can determine if it is possible to meet them.


    Note, Linz_H_Hat CAN'T "Contradict" itself, as doesn't generate >>>>>>>> any truth values, only behavior. You are just showing that you >>>>>>>> don't understand the basics of the requirements, and seem to
    think that "close" is good enough for proofs.

    Linz_H_Hat(Linz_H_Hat) returns 0.

    Actually no. Linz_H_Hat(Linz_H_Hat) halts at state Qn, which has NO >>>>>> defined meaning for Linz_H_Hat as it isn't defined to be a decider. >>>>>
    Linz_H and Linz_H_Hat are C functions.
    Linz:H and Linz:Ĥ are Turing machines.

    So, inventing new terminology without introduction, thus showing you
    are being intentionally deceptive.


    Linz_H and Linz:H are both directly embedded within a copy of
    Linz_H_Hat and Linz:Ĥ thus a return value of 0 or a transition
    to Ĥ.qn still means not halting.

    No, because Linz_H_Hat / Linz:Ĥ are not "Halt Deciders" so there
    return value has no meaning.

    Ĥ has no meaning, so it can't be "incorrect" or contradicted.


    This allows Linz_H and Linz:H correctly report on the actual
    behavior of their input.



    No, since BOTH have an input that when run will HALT, and both
    report that it will not, both are just wrong.

    Linz_H(Linz_H_Hat, Linz_H_Hat) is claimed to "correctly" return 0,
    *I never said that you are confused*

    You always claim that your H by its various names is "Correct" to
    return 0 as the input is non-halting because its "correct simulation"
    will never reach a final state.

    I think your brain is turning into mush, or is your pathology
    overloading and trying to reverse the argument.

    Linz_H_Hat(Linz_H_Hat) returns 0 permitting
    Linz_H(Linz_H_Hat, Linz_H_Hat) to correctly return 1.


    But if Linz_H(Linz_H_Hat, Linz_H_Hat) returns 1, which means Halting,

    Linz_H_Hat has its own embedded_H that returns 0.
    Linz_H_Hat has no access to Linz_H, only to its own embedded copy.

    But embedded_H is an identical copy to Linz_H, so if embedded_H returns
    0, so does Lin

    Linz_H simply simulates Linz_H_Hat until it terminates.

    Then so must embedded_H, since it is an identical copy, and as you have
    shown before, if H is defined that way, the H_Hat will never halt, and
    thus H, since for this case you said it doesn't abort, will also never
    halt and fail to be a decider.

    Now, since you are claiming that the embedded_H and Linz_H are IDENTICAL machines, but the also produce DIFFERENT results when given identical
    inputs, you have just proven that you are a LIAR. A totally Pathologica
    LIAR, that must believe in Faery Dust Powered Unicorn with Magic Wands
    to make these two identical machines do different things.

    This PROVES that you are just STUPID if you think people will beleive
    your blatant lies.


    it means that Linz_H_Hat will go into the infinte loop on the Qy leg.

    Did you miss that parto of the design in Linz's proof. H^ has modified
    the end of H so that Qy becomes a non-terminal state.

    Linz_H_Hat doesn't actually "return" a value, it just goes to Qn and

    Linz_H_Hat is a C function Linz:Ĥ is a Turing machine.
    They use the exact same algorithm.


    So. Linz_H_Hat doesn't return a value that has semantic value.

    You are just off serving more Red Herring.


    halt or never halts.



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Richard Damon on Mon Jul 3 22:56:47 2023
    XPost: comp.theory, sci.logic

    On 7/3/2023 10:22 PM, Richard Damon wrote:
    On 7/3/23 10:20 PM, olcott wrote:
    On 7/3/2023 4:55 PM, Richard Damon wrote:
    On 7/3/23 5:34 PM, olcott wrote:
    On 7/3/2023 4:17 PM, Richard Damon wrote:
    On 7/3/23 4:22 PM, olcott wrote:
    On 7/3/2023 2:58 PM, Richard Damon wrote:
    On 7/3/23 2:48 PM, olcott wrote:
    On 7/3/2023 1:25 PM, Richard Damon wrote:
    On 7/3/23 1:57 PM, olcott wrote:
    On 7/3/2023 11:26 AM, Richard Damon wrote:
    On 7/3/23 12:11 PM, olcott wrote:
    On 7/3/2023 11:01 AM, Richard Damon wrote:
    On 7/3/23 11:56 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 10:45 AM, olcott wrote:
    On 7/3/2023 9:24 AM, Richard Damon wrote:
    On 7/3/23 9:47 AM, olcott wrote:
    On 7/3/2023 8:14 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>> On 7/2/23 10:48 PM, olcott wrote:
    On 7/2/2023 9:41 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>> On 7/2/23 10:01 PM, olcott wrote:
    On 7/2/2023 8:40 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>> On 7/2/23 8:45 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>> A single H can consistently correctly determine >>>>>>>>>>>>>>>>>>>>>>>> whether or not its input
    is pathological relative to itself. When H(D,D) >>>>>>>>>>>>>>>>>>>>>>>> is invoked in
    decidability decider mode determines that D is >>>>>>>>>>>>>>>>>>>>>>>> pathological relative to
    itself this enables a batch file to invoke >>>>>>>>>>>>>>>>>>>>>>>> H1(D,D) to get the actual
    behavior of the directly executed D(D). H1 is >>>>>>>>>>>>>>>>>>>>>>>> identical to H except for
    the pathological relationship to H. >>>>>>>>>>>>>>>>>>>>>>>>


    And does an input D that uses this FULL algorithm >>>>>>>>>>>>>>>>>>>>>>> give your algorithm problems?

    Since H(D,D) will (apparently) determine that the >>>>>>>>>>>>>>>>>>>>>>> input is pathological, and thus defer to H1(D,D), >>>>>>>>>>>>>>>>>>>>>>> then when we actually run D, appearently it will >>>>>>>>>>>>>>>>>>>>>>> get that same answer from H1 and do the opposite >>>>>>>>>>>>>>>>>>>>>>> of it, and thus H1 will be wrong. >>>>>>>>>>>>>>>>>>>>>>>
    Remember, the "Pathological" program is built on >>>>>>>>>>>>>>>>>>>>>>> a copy of the ACTUAL program that you ask to >>>>>>>>>>>>>>>>>>>>>>> decide on it, including ALL of its "tricks", >>>>>>>>>>>>>>>>>>>>>>> including things like this "batch processing". >>>>>>>>>>>>>>>>>>>>>>>
    You seem to be assuming that there is some >>>>>>>>>>>>>>>>>>>>>>> "Operationg System" outside the Decider - Input >>>>>>>>>>>>>>>>>>>>>>> structure, but there isn't, at least not one that >>>>>>>>>>>>>>>>>>>>>>> can affect the answer of the problem. >>>>>>>>>>>>>>>>>>>>>>
    I spent 12 hours a day for the last 10 days >>>>>>>>>>>>>>>>>>>>>> getting the copy the input
    working. When H(D,D) (in decidability decider >>>>>>>>>>>>>>>>>>>>>> mode) detects that its
    input is in the well defined set of pathological >>>>>>>>>>>>>>>>>>>>>> inputs it returns 0
    indicating that its input is undecidable. The >>>>>>>>>>>>>>>>>>>>>> batch file that invoked H
    then knows to invoke H1(D,D) to correctly report >>>>>>>>>>>>>>>>>>>>>> that D(D) halts.

    This solution does seem to work correctly on every >>>>>>>>>>>>>>>>>>>>>> conventional proof in
    every textbook.


    So, did you make your "conventional proof" template >>>>>>>>>>>>>>>>>>>>> actually use a copy of your ACTUAL decider (which >>>>>>>>>>>>>>>>>>>>> seems to be your "batch file" not the C funciton >>>>>>>>>>>>>>>>>>>>> H), or are you just admitting that you wasted 120 >>>>>>>>>>>>>>>>>>>>> hours looking at the wrong thing because you have >>>>>>>>>>>>>>>>>>>>> made yourself intentionally ignorant of the subject >>>>>>>>>>>>>>>>>>>>> so you don't understand what you are trying to do. >>>>>>>>>>>>>>>>>>>>
    New_D copies its input and simulates its input with >>>>>>>>>>>>>>>>>>>> its input.
    It never sees New_H.


    Why not? Since New_H is the thing that is considered >>>>>>>>>>>>>>>>>>> the "Correct Halt Decider", New_D needs to be built >>>>>>>>>>>>>>>>>>> on it.


    New_H is embedded within New_D (as its middle states) >>>>>>>>>>>>>>>>>> just the
    way it is supposed to be. The question is: Does >>>>>>>>>>>>>>>>>> New_H(New_H) halt?

    The only difference at the source code level is: >>>>>>>>>>>>>>>>>> (a) New_H copies its input, thus takes one param. >>>>>>>>>>>>>>>>>> (b) New_H has an infinite loop at its accept state. >>>>>>>>>>>>>>>>>
    So, how is New_H a halt decider then?

    typo
    The only difference at the source code level is: >>>>>>>>>>>>>>>> (a) New_D copies its input, thus takes one param. >>>>>>>>>>>>>>>> (b) New_D has an infinite loop at its accept state. >>>>>>>>>>>>>>>> Other than that (at the source-code level) New_D is >>>>>>>>>>>>>>>> exactly New_H



    But New_D needs to call New_H,

    Not in the Peter Linz proof:
    https://www.liarparadox.org/Linz_Proof.pdf

    In the Linz proof a copy of H is directly embedded >>>>>>>>>>>>>> within Ĥ at this state: Ĥq0 Wm Wm
    The original H remains unchanged.

    The halting problem is about undecidable inputs, it is not >>>>>>>>>>>>>> about
    inserting bugs into a halt decider to make it cease to >>>>>>>>>>>>>> function.



    Right, and in Linz, H is the decider that is claimed to >>>>>>>>>>>>> give the right answer.

    That isn't 'H' in your system, but the script that decides >>>>>>>>>>>>> whether to use H or H1.

    Your error is in calling the wrong thing 'H'

    You are just showing you are lying by using the wrong name >>>>>>>>>>>>> for things.

    You are using double-talk in a lame attempt to show that >>>>>>>>>>>> Linz H cannot correctly determine the halt status of Linz Ĥ. >>>>>>>>>>>>

    So you agree with the Theorem.

    No 'Linz H' can exist that correctly decides the halt status >>>>>>>>>>> of Linz Ĥ applied to the description of Linz Ĥ.

    That is EXACTLY the consequence of the Halting Theorem.


    Please show an ACTUAL 'Linz H' that correctly gets the
    results of the 'Linz Ĥ' built on it. You keep on changing H >>>>>>>>>>> and trying to use the old Ĥ which just fails to meet the >>>>>>>>>>> requirement of the proof, likely because you just don't
    understand the theory involved.

    It took me two years to figure out a clean way to copy the >>>>>>>>>> input to
    Linz_H_Hat and not have the system crash. Relative to Linz_H_Hat >>>>>>>>>> Linz_H is H1. Now Linz_H_Hat only contradicts itself.


    So, you are admitting that you actually can't do what is required? >>>>>>>>>
    Copying the input should be trivial,

    The relative addressing of the x86 language causes all function >>>>>>>> calls to call the wrong address.

    Only because you aren't interpreting the input properly, but in a >>>>>>> non-Turing Complete manner.

    As I said, the input description should be a chunck of code in a >>>>>>> virtual address space with a header that tells where that code is >>>>>>> supposed to be considered to be located at.


    as the input should be a representation that packages a full >>>>>>>>> program in its own virtual environment, so a simple bit by bit >>>>>>>>> copy to empty ram will work. Your problem is that you don't put >>>>>>>>> the input into its own virtual address space, so you have
    pathological interactions.

    Linz_H_Hat must be built on the exact code base that is
    deciding on it, in this case H, since you just said it isn't, >>>>>>>>> your proof is invalid.


    Linz_Hat <is> Linz_H that takes one param  and copies it instead of >>>>>>>> two params and has an infinite loop at its accept state.

    So, Two things that are different are exactly the same?


    It exactly matches the Linz spec.

    You don't seem to understand what you are doing.

    Linz_H_Hat (not Linz_Hat) is a Turing Machine with a defined
    behavior. That behavior is a function of its input, but hasn't
    been assigned any "meaning".

    Linz_H is a Turing Machine (if it actually can exist) that has a >>>>>>> defined meaning/requirement for its final states. Linz_H, to meet >>>>>>> its requirements, MUST go to Qy if the input represents a Halting >>>>>>> Computation, and MUST go to Qn if the input represents a
    non-halting computation.

    Since Linz_H has actual requirements, a claimed implementation of >>>>>>> it can be checked to see if it actually meets the requirements,
    and perhaps we can determine if it is possible to meet them.


    Note, Linz_H_Hat CAN'T "Contradict" itself, as doesn't generate >>>>>>>>> any truth values, only behavior. You are just showing that you >>>>>>>>> don't understand the basics of the requirements, and seem to >>>>>>>>> think that "close" is good enough for proofs.

    Linz_H_Hat(Linz_H_Hat) returns 0.

    Actually no. Linz_H_Hat(Linz_H_Hat) halts at state Qn, which
    has NO
    defined meaning for Linz_H_Hat as it isn't defined to be a decider. >>>>>>
    Linz_H and Linz_H_Hat are C functions.
    Linz:H and Linz:Ĥ are Turing machines.

    So, inventing new terminology without introduction, thus showing
    you are being intentionally deceptive.


    Linz_H and Linz:H are both directly embedded within a copy of
    Linz_H_Hat and Linz:Ĥ thus a return value of 0 or a transition
    to Ĥ.qn still means not halting.

    No, because Linz_H_Hat / Linz:Ĥ are not "Halt Deciders" so there
    return value has no meaning.

    Ĥ has no meaning, so it can't be "incorrect" or contradicted.


    This allows Linz_H and Linz:H correctly report on the actual
    behavior of their input.



    No, since BOTH have an input that when run will HALT, and both
    report that it will not, both are just wrong.

    Linz_H(Linz_H_Hat, Linz_H_Hat) is claimed to "correctly" return 0,
    *I never said that you are confused*

    You always claim that your H by its various names is "Correct" to
    return 0 as the input is non-halting because its "correct simulation"
    will never reach a final state.

    I think your brain is turning into mush, or is your pathology
    overloading and trying to reverse the argument.

    Linz_H_Hat(Linz_H_Hat) returns 0 permitting
    Linz_H(Linz_H_Hat, Linz_H_Hat) to correctly return 1.


    But if Linz_H(Linz_H_Hat, Linz_H_Hat) returns 1, which means Halting,

    Linz_H_Hat has its own embedded_H that returns 0.
    Linz_H_Hat has no access to Linz_H, only to its own embedded copy.

    But embedded_H is an identical copy to Linz_H, so if embedded_H returns
    0, so does Lin

    Linz_H simply simulates Linz_H_Hat until it terminates.

    Then so must embedded_H, since it is an identical copy, and as you have
    shown before, if H is defined that way, the H_Hat will never halt, and
    thus H, since for this case you said it doesn't abort, will also never
    halt and fail to be a decider.


    We have gone through this many hundreds of times.
    It is the exact same H(D,D) versus H1(D,D) thing.

    Linz_H_Hat now has a pathological relationship to itself
    this frees Linz_H from such a pathological relationship.
    So Linz_H becomes H1, and Linz_H_Hat becomes H.

    Now, since you are claiming that the embedded_H and Linz_H are IDENTICAL machines, but the also produce DIFFERENT results when given identical
    inputs, you have just proven that you are a LIAR.

    *So you are back to rejecting verified facts out-of-hand*
    It is a verified fact that H(D,D) returns 0 and H1(D,D) returns
    1 and the only difference is that H1 does not have a pathological
    relationship to H and it is otherwise identical to H.




    --
    Copyright 2023 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 Jul 4 00:06:43 2023
    XPost: comp.theory, sci.logic

    On 7/3/23 11:56 PM, olcott wrote:
    On 7/3/2023 10:22 PM, Richard Damon wrote:
    On 7/3/23 10:20 PM, olcott wrote:
    On 7/3/2023 4:55 PM, Richard Damon wrote:
    On 7/3/23 5:34 PM, olcott wrote:
    On 7/3/2023 4:17 PM, Richard Damon wrote:
    On 7/3/23 4:22 PM, olcott wrote:
    On 7/3/2023 2:58 PM, Richard Damon wrote:
    On 7/3/23 2:48 PM, olcott wrote:
    On 7/3/2023 1:25 PM, Richard Damon wrote:
    On 7/3/23 1:57 PM, olcott wrote:
    On 7/3/2023 11:26 AM, Richard Damon wrote:
    On 7/3/23 12:11 PM, olcott wrote:
    On 7/3/2023 11:01 AM, Richard Damon wrote:
    On 7/3/23 11:56 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 10:45 AM, olcott wrote:
    On 7/3/2023 9:24 AM, Richard Damon wrote:
    On 7/3/23 9:47 AM, olcott wrote:
    On 7/3/2023 8:14 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 7/2/23 10:48 PM, olcott wrote:
    On 7/2/2023 9:41 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>> On 7/2/23 10:01 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>> On 7/2/2023 8:40 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 7/2/23 8:45 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>> A single H can consistently correctly determine >>>>>>>>>>>>>>>>>>>>>>>>> whether or not its input
    is pathological relative to itself. When H(D,D) >>>>>>>>>>>>>>>>>>>>>>>>> is invoked in
    decidability decider mode determines that D is >>>>>>>>>>>>>>>>>>>>>>>>> pathological relative to
    itself this enables a batch file to invoke >>>>>>>>>>>>>>>>>>>>>>>>> H1(D,D) to get the actual
    behavior of the directly executed D(D). H1 is >>>>>>>>>>>>>>>>>>>>>>>>> identical to H except for
    the pathological relationship to H. >>>>>>>>>>>>>>>>>>>>>>>>>


    And does an input D that uses this FULL >>>>>>>>>>>>>>>>>>>>>>>> algorithm give your algorithm problems? >>>>>>>>>>>>>>>>>>>>>>>>
    Since H(D,D) will (apparently) determine that >>>>>>>>>>>>>>>>>>>>>>>> the input is pathological, and thus defer to >>>>>>>>>>>>>>>>>>>>>>>> H1(D,D), then when we actually run D, >>>>>>>>>>>>>>>>>>>>>>>> appearently it will get that same answer from H1 >>>>>>>>>>>>>>>>>>>>>>>> and do the opposite of it, and thus H1 will be >>>>>>>>>>>>>>>>>>>>>>>> wrong.

    Remember, the "Pathological" program is built on >>>>>>>>>>>>>>>>>>>>>>>> a copy of the ACTUAL program that you ask to >>>>>>>>>>>>>>>>>>>>>>>> decide on it, including ALL of its "tricks", >>>>>>>>>>>>>>>>>>>>>>>> including things like this "batch processing". >>>>>>>>>>>>>>>>>>>>>>>>
    You seem to be assuming that there is some >>>>>>>>>>>>>>>>>>>>>>>> "Operationg System" outside the Decider - Input >>>>>>>>>>>>>>>>>>>>>>>> structure, but there isn't, at least not one >>>>>>>>>>>>>>>>>>>>>>>> that can affect the answer of the problem. >>>>>>>>>>>>>>>>>>>>>>>
    I spent 12 hours a day for the last 10 days >>>>>>>>>>>>>>>>>>>>>>> getting the copy the input
    working. When H(D,D) (in decidability decider >>>>>>>>>>>>>>>>>>>>>>> mode) detects that its
    input is in the well defined set of pathological >>>>>>>>>>>>>>>>>>>>>>> inputs it returns 0
    indicating that its input is undecidable. The >>>>>>>>>>>>>>>>>>>>>>> batch file that invoked H
    then knows to invoke H1(D,D) to correctly report >>>>>>>>>>>>>>>>>>>>>>> that D(D) halts.

    This solution does seem to work correctly on >>>>>>>>>>>>>>>>>>>>>>> every conventional proof in
    every textbook.


    So, did you make your "conventional proof" >>>>>>>>>>>>>>>>>>>>>> template actually use a copy of your ACTUAL >>>>>>>>>>>>>>>>>>>>>> decider (which seems to be your "batch file" not >>>>>>>>>>>>>>>>>>>>>> the C funciton H), or are you just admitting that >>>>>>>>>>>>>>>>>>>>>> you wasted 120 hours looking at the wrong thing >>>>>>>>>>>>>>>>>>>>>> because you have made yourself intentionally >>>>>>>>>>>>>>>>>>>>>> ignorant of the subject so you don't understand >>>>>>>>>>>>>>>>>>>>>> what you are trying to do.

    New_D copies its input and simulates its input with >>>>>>>>>>>>>>>>>>>>> its input.
    It never sees New_H.


    Why not? Since New_H is the thing that is considered >>>>>>>>>>>>>>>>>>>> the "Correct Halt Decider", New_D needs to be built >>>>>>>>>>>>>>>>>>>> on it.


    New_H is embedded within New_D (as its middle states) >>>>>>>>>>>>>>>>>>> just the
    way it is supposed to be. The question is: Does >>>>>>>>>>>>>>>>>>> New_H(New_H) halt?

    The only difference at the source code level is: >>>>>>>>>>>>>>>>>>> (a) New_H copies its input, thus takes one param. >>>>>>>>>>>>>>>>>>> (b) New_H has an infinite loop at its accept state. >>>>>>>>>>>>>>>>>>
    So, how is New_H a halt decider then?

    typo
    The only difference at the source code level is: >>>>>>>>>>>>>>>>> (a) New_D copies its input, thus takes one param. >>>>>>>>>>>>>>>>> (b) New_D has an infinite loop at its accept state. >>>>>>>>>>>>>>>>> Other than that (at the source-code level) New_D is >>>>>>>>>>>>>>>>> exactly New_H



    But New_D needs to call New_H,

    Not in the Peter Linz proof:
    https://www.liarparadox.org/Linz_Proof.pdf

    In the Linz proof a copy of H is directly embedded >>>>>>>>>>>>>>> within Ĥ at this state: Ĥq0 Wm Wm
    The original H remains unchanged.

    The halting problem is about undecidable inputs, it is >>>>>>>>>>>>>>> not about
    inserting bugs into a halt decider to make it cease to >>>>>>>>>>>>>>> function.



    Right, and in Linz, H is the decider that is claimed to >>>>>>>>>>>>>> give the right answer.

    That isn't 'H' in your system, but the script that decides >>>>>>>>>>>>>> whether to use H or H1.

    Your error is in calling the wrong thing 'H'

    You are just showing you are lying by using the wrong name >>>>>>>>>>>>>> for things.

    You are using double-talk in a lame attempt to show that >>>>>>>>>>>>> Linz H cannot correctly determine the halt status of Linz Ĥ. >>>>>>>>>>>>>

    So you agree with the Theorem.

    No 'Linz H' can exist that correctly decides the halt status >>>>>>>>>>>> of Linz Ĥ applied to the description of Linz Ĥ.

    That is EXACTLY the consequence of the Halting Theorem. >>>>>>>>>>>>

    Please show an ACTUAL 'Linz H' that correctly gets the >>>>>>>>>>>> results of the 'Linz Ĥ' built on it. You keep on changing H >>>>>>>>>>>> and trying to use the old Ĥ which just fails to meet the >>>>>>>>>>>> requirement of the proof, likely because you just don't >>>>>>>>>>>> understand the theory involved.

    It took me two years to figure out a clean way to copy the >>>>>>>>>>> input to
    Linz_H_Hat and not have the system crash. Relative to Linz_H_Hat >>>>>>>>>>> Linz_H is H1. Now Linz_H_Hat only contradicts itself.


    So, you are admitting that you actually can't do what is
    required?

    Copying the input should be trivial,

    The relative addressing of the x86 language causes all function >>>>>>>>> calls to call the wrong address.

    Only because you aren't interpreting the input properly, but in >>>>>>>> a non-Turing Complete manner.

    As I said, the input description should be a chunck of code in a >>>>>>>> virtual address space with a header that tells where that code >>>>>>>> is supposed to be considered to be located at.


    as the input should be a representation that packages a full >>>>>>>>>> program in its own virtual environment, so a simple bit by bit >>>>>>>>>> copy to empty ram will work. Your problem is that you don't >>>>>>>>>> put the input into its own virtual address space, so you have >>>>>>>>>> pathological interactions.

    Linz_H_Hat must be built on the exact code base that is
    deciding on it, in this case H, since you just said it isn't, >>>>>>>>>> your proof is invalid.


    Linz_Hat <is> Linz_H that takes one param  and copies it
    instead of
    two params and has an infinite loop at its accept state.

    So, Two things that are different are exactly the same?


    It exactly matches the Linz spec.

    You don't seem to understand what you are doing.

    Linz_H_Hat (not Linz_Hat) is a Turing Machine with a defined
    behavior. That behavior is a function of its input, but hasn't >>>>>>>> been assigned any "meaning".

    Linz_H is a Turing Machine (if it actually can exist) that has a >>>>>>>> defined meaning/requirement for its final states. Linz_H, to
    meet its requirements, MUST go to Qy if the input represents a >>>>>>>> Halting Computation, and MUST go to Qn if the input represents a >>>>>>>> non-halting computation.

    Since Linz_H has actual requirements, a claimed implementation >>>>>>>> of it can be checked to see if it actually meets the
    requirements, and perhaps we can determine if it is possible to >>>>>>>> meet them.


    Note, Linz_H_Hat CAN'T "Contradict" itself, as doesn't
    generate any truth values, only behavior. You are just showing >>>>>>>>>> that you don't understand the basics of the requirements, and >>>>>>>>>> seem to think that "close" is good enough for proofs.

    Linz_H_Hat(Linz_H_Hat) returns 0.

    Actually no. Linz_H_Hat(Linz_H_Hat) halts at state Qn, which >>>>>>>> has NO
    defined meaning for Linz_H_Hat as it isn't defined to be a decider. >>>>>>>
    Linz_H and Linz_H_Hat are C functions.
    Linz:H and Linz:Ĥ are Turing machines.

    So, inventing new terminology without introduction, thus showing
    you are being intentionally deceptive.


    Linz_H and Linz:H are both directly embedded within a copy of
    Linz_H_Hat and Linz:Ĥ thus a return value of 0 or a transition
    to Ĥ.qn still means not halting.

    No, because Linz_H_Hat / Linz:Ĥ are not "Halt Deciders" so there
    return value has no meaning.

    Ĥ has no meaning, so it can't be "incorrect" or contradicted.


    This allows Linz_H and Linz:H correctly report on the actual
    behavior of their input.



    No, since BOTH have an input that when run will HALT, and both
    report that it will not, both are just wrong.

    Linz_H(Linz_H_Hat, Linz_H_Hat) is claimed to "correctly" return 0,
    *I never said that you are confused*

    You always claim that your H by its various names is "Correct" to
    return 0 as the input is non-halting because its "correct
    simulation" will never reach a final state.

    I think your brain is turning into mush, or is your pathology
    overloading and trying to reverse the argument.

    Linz_H_Hat(Linz_H_Hat) returns 0 permitting
    Linz_H(Linz_H_Hat, Linz_H_Hat) to correctly return 1.


    But if Linz_H(Linz_H_Hat, Linz_H_Hat) returns 1, which means Halting,

    Linz_H_Hat has its own embedded_H that returns 0.
    Linz_H_Hat has no access to Linz_H, only to its own embedded copy.

    But embedded_H is an identical copy to Linz_H, so if embedded_H
    returns 0, so does Lin

    Linz_H simply simulates Linz_H_Hat until it terminates.

    Then so must embedded_H, since it is an identical copy, and as you
    have shown before, if H is defined that way, the H_Hat will never
    halt, and thus H, since for this case you said it doesn't abort, will
    also never halt and fail to be a decider.


    We have gone through this many hundreds of times.
    It is the exact same H(D,D) versus H1(D,D) thing.

    Linz_H_Hat now has a pathological relationship to itself
    this frees Linz_H from such a pathological relationship.
    So Linz_H becomes H1, and Linz_H_Hat becomes H.

    Nope, just shows you are not working in a Turing Equivalent system, and
    thus NOTHING you say matters.


    Now, since you are claiming that the embedded_H and Linz_H are
    IDENTICAL machines, but the also produce DIFFERENT results when given
    identical inputs, you have just proven that you are a LIAR.

    *So you are back to rejecting verified facts out-of-hand*
    It is a verified fact that H(D,D) returns 0 and H1(D,D) returns
    1 and the only difference is that H1 does not have a pathological relationship to H and it is otherwise identical to H.


    Since youy refuse to provide the verification fact about where the paths
    of H(D,D) and D(D) differ, you don't HAVE a "verified fact".

    You are just proving that you are just a LIAR and an IDIOT.

    What IS verified is that D(D) Halts, so H(D,D) returning 0 is BY
    DEFINITION WRONG and you claim tha tit is right is a verified LIE.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Richard Damon on Mon Jul 3 23:57:25 2023
    XPost: comp.theory, sci.logic

    On 7/3/2023 11:06 PM, Richard Damon wrote:
    On 7/3/23 11:56 PM, olcott wrote:
    On 7/3/2023 10:22 PM, Richard Damon wrote:
    On 7/3/23 10:20 PM, olcott wrote:
    On 7/3/2023 4:55 PM, Richard Damon wrote:
    On 7/3/23 5:34 PM, olcott wrote:
    On 7/3/2023 4:17 PM, Richard Damon wrote:
    On 7/3/23 4:22 PM, olcott wrote:
    On 7/3/2023 2:58 PM, Richard Damon wrote:
    On 7/3/23 2:48 PM, olcott wrote:
    On 7/3/2023 1:25 PM, Richard Damon wrote:
    On 7/3/23 1:57 PM, olcott wrote:
    On 7/3/2023 11:26 AM, Richard Damon wrote:
    On 7/3/23 12:11 PM, olcott wrote:
    On 7/3/2023 11:01 AM, Richard Damon wrote:
    On 7/3/23 11:56 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 10:45 AM, olcott wrote:
    On 7/3/2023 9:24 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>> On 7/3/23 9:47 AM, olcott wrote:
    On 7/3/2023 8:14 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>> On 7/2/23 10:48 PM, olcott wrote:
    On 7/2/2023 9:41 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>> On 7/2/23 10:01 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 7/2/2023 8:40 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 7/2/23 8:45 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> A single H can consistently correctly >>>>>>>>>>>>>>>>>>>>>>>>>> determine whether or not its input >>>>>>>>>>>>>>>>>>>>>>>>>> is pathological relative to itself. When >>>>>>>>>>>>>>>>>>>>>>>>>> H(D,D) is invoked in
    decidability decider mode determines that D is >>>>>>>>>>>>>>>>>>>>>>>>>> pathological relative to
    itself this enables a batch file to invoke >>>>>>>>>>>>>>>>>>>>>>>>>> H1(D,D) to get the actual
    behavior of the directly executed D(D). H1 is >>>>>>>>>>>>>>>>>>>>>>>>>> identical to H except for
    the pathological relationship to H. >>>>>>>>>>>>>>>>>>>>>>>>>>


    And does an input D that uses this FULL >>>>>>>>>>>>>>>>>>>>>>>>> algorithm give your algorithm problems? >>>>>>>>>>>>>>>>>>>>>>>>>
    Since H(D,D) will (apparently) determine that >>>>>>>>>>>>>>>>>>>>>>>>> the input is pathological, and thus defer to >>>>>>>>>>>>>>>>>>>>>>>>> H1(D,D), then when we actually run D, >>>>>>>>>>>>>>>>>>>>>>>>> appearently it will get that same answer from >>>>>>>>>>>>>>>>>>>>>>>>> H1 and do the opposite of it, and thus H1 will >>>>>>>>>>>>>>>>>>>>>>>>> be wrong.

    Remember, the "Pathological" program is built >>>>>>>>>>>>>>>>>>>>>>>>> on a copy of the ACTUAL program that you ask to >>>>>>>>>>>>>>>>>>>>>>>>> decide on it, including ALL of its "tricks", >>>>>>>>>>>>>>>>>>>>>>>>> including things like this "batch processing". >>>>>>>>>>>>>>>>>>>>>>>>>
    You seem to be assuming that there is some >>>>>>>>>>>>>>>>>>>>>>>>> "Operationg System" outside the Decider - Input >>>>>>>>>>>>>>>>>>>>>>>>> structure, but there isn't, at least not one >>>>>>>>>>>>>>>>>>>>>>>>> that can affect the answer of the problem. >>>>>>>>>>>>>>>>>>>>>>>>
    I spent 12 hours a day for the last 10 days >>>>>>>>>>>>>>>>>>>>>>>> getting the copy the input
    working. When H(D,D) (in decidability decider >>>>>>>>>>>>>>>>>>>>>>>> mode) detects that its
    input is in the well defined set of pathological >>>>>>>>>>>>>>>>>>>>>>>> inputs it returns 0
    indicating that its input is undecidable. The >>>>>>>>>>>>>>>>>>>>>>>> batch file that invoked H
    then knows to invoke H1(D,D) to correctly report >>>>>>>>>>>>>>>>>>>>>>>> that D(D) halts.

    This solution does seem to work correctly on >>>>>>>>>>>>>>>>>>>>>>>> every conventional proof in
    every textbook.


    So, did you make your "conventional proof" >>>>>>>>>>>>>>>>>>>>>>> template actually use a copy of your ACTUAL >>>>>>>>>>>>>>>>>>>>>>> decider (which seems to be your "batch file" not >>>>>>>>>>>>>>>>>>>>>>> the C funciton H), or are you just admitting that >>>>>>>>>>>>>>>>>>>>>>> you wasted 120 hours looking at the wrong thing >>>>>>>>>>>>>>>>>>>>>>> because you have made yourself intentionally >>>>>>>>>>>>>>>>>>>>>>> ignorant of the subject so you don't understand >>>>>>>>>>>>>>>>>>>>>>> what you are trying to do.

    New_D copies its input and simulates its input >>>>>>>>>>>>>>>>>>>>>> with its input.
    It never sees New_H.


    Why not? Since New_H is the thing that is >>>>>>>>>>>>>>>>>>>>> considered the "Correct Halt Decider", New_D needs >>>>>>>>>>>>>>>>>>>>> to be built on it.


    New_H is embedded within New_D (as its middle >>>>>>>>>>>>>>>>>>>> states) just the
    way it is supposed to be. The question is: Does >>>>>>>>>>>>>>>>>>>> New_H(New_H) halt?

    The only difference at the source code level is: >>>>>>>>>>>>>>>>>>>> (a) New_H copies its input, thus takes one param. >>>>>>>>>>>>>>>>>>>> (b) New_H has an infinite loop at its accept state. >>>>>>>>>>>>>>>>>>>
    So, how is New_H a halt decider then?

    typo
    The only difference at the source code level is: >>>>>>>>>>>>>>>>>> (a) New_D copies its input, thus takes one param. >>>>>>>>>>>>>>>>>> (b) New_D has an infinite loop at its accept state. >>>>>>>>>>>>>>>>>> Other than that (at the source-code level) New_D is >>>>>>>>>>>>>>>>>> exactly New_H



    But New_D needs to call New_H,

    Not in the Peter Linz proof:
    https://www.liarparadox.org/Linz_Proof.pdf

    In the Linz proof a copy of H is directly embedded >>>>>>>>>>>>>>>> within Ĥ at this state: Ĥq0 Wm Wm
    The original H remains unchanged.

    The halting problem is about undecidable inputs, it is >>>>>>>>>>>>>>>> not about
    inserting bugs into a halt decider to make it cease to >>>>>>>>>>>>>>>> function.



    Right, and in Linz, H is the decider that is claimed to >>>>>>>>>>>>>>> give the right answer.

    That isn't 'H' in your system, but the script that >>>>>>>>>>>>>>> decides whether to use H or H1.

    Your error is in calling the wrong thing 'H'

    You are just showing you are lying by using the wrong >>>>>>>>>>>>>>> name for things.

    You are using double-talk in a lame attempt to show that >>>>>>>>>>>>>> Linz H cannot correctly determine the halt status of Linz Ĥ. >>>>>>>>>>>>>>

    So you agree with the Theorem.

    No 'Linz H' can exist that correctly decides the halt >>>>>>>>>>>>> status of Linz Ĥ applied to the description of Linz Ĥ. >>>>>>>>>>>>>
    That is EXACTLY the consequence of the Halting Theorem. >>>>>>>>>>>>>

    Please show an ACTUAL 'Linz H' that correctly gets the >>>>>>>>>>>>> results of the 'Linz Ĥ' built on it. You keep on changing H >>>>>>>>>>>>> and trying to use the old Ĥ which just fails to meet the >>>>>>>>>>>>> requirement of the proof, likely because you just don't >>>>>>>>>>>>> understand the theory involved.

    It took me two years to figure out a clean way to copy the >>>>>>>>>>>> input to
    Linz_H_Hat and not have the system crash. Relative to
    Linz_H_Hat
    Linz_H is H1. Now Linz_H_Hat only contradicts itself.


    So, you are admitting that you actually can't do what is >>>>>>>>>>> required?

    Copying the input should be trivial,

    The relative addressing of the x86 language causes all function >>>>>>>>>> calls to call the wrong address.

    Only because you aren't interpreting the input properly, but in >>>>>>>>> a non-Turing Complete manner.

    As I said, the input description should be a chunck of code in >>>>>>>>> a virtual address space with a header that tells where that
    code is supposed to be considered to be located at.


    as the input should be a representation that packages a full >>>>>>>>>>> program in its own virtual environment, so a simple bit by >>>>>>>>>>> bit copy to empty ram will work. Your problem is that you >>>>>>>>>>> don't put the input into its own virtual address space, so >>>>>>>>>>> you have pathological interactions.

    Linz_H_Hat must be built on the exact code base that is
    deciding on it, in this case H, since you just said it isn't, >>>>>>>>>>> your proof is invalid.


    Linz_Hat <is> Linz_H that takes one param  and copies it
    instead of
    two params and has an infinite loop at its accept state.

    So, Two things that are different are exactly the same?


    It exactly matches the Linz spec.

    You don't seem to understand what you are doing.

    Linz_H_Hat (not Linz_Hat) is a Turing Machine with a defined >>>>>>>>> behavior. That behavior is a function of its input, but hasn't >>>>>>>>> been assigned any "meaning".

    Linz_H is a Turing Machine (if it actually can exist) that has >>>>>>>>> a defined meaning/requirement for its final states. Linz_H, to >>>>>>>>> meet its requirements, MUST go to Qy if the input represents a >>>>>>>>> Halting Computation, and MUST go to Qn if the input represents >>>>>>>>> a non-halting computation.

    Since Linz_H has actual requirements, a claimed implementation >>>>>>>>> of it can be checked to see if it actually meets the
    requirements, and perhaps we can determine if it is possible to >>>>>>>>> meet them.


    Note, Linz_H_Hat CAN'T "Contradict" itself, as doesn't
    generate any truth values, only behavior. You are just
    showing that you don't understand the basics of the
    requirements, and seem to think that "close" is good enough >>>>>>>>>>> for proofs.

    Linz_H_Hat(Linz_H_Hat) returns 0.

    Actually no. Linz_H_Hat(Linz_H_Hat) halts at state Qn, which >>>>>>>>> has NO
    defined meaning for Linz_H_Hat as it isn't defined to be a
    decider.

    Linz_H and Linz_H_Hat are C functions.
    Linz:H and Linz:Ĥ are Turing machines.

    So, inventing new terminology without introduction, thus showing >>>>>>> you are being intentionally deceptive.


    Linz_H and Linz:H are both directly embedded within a copy of
    Linz_H_Hat and Linz:Ĥ thus a return value of 0 or a transition >>>>>>>> to Ĥ.qn still means not halting.

    No, because Linz_H_Hat / Linz:Ĥ are not "Halt Deciders" so there >>>>>>> return value has no meaning.

    Ĥ has no meaning, so it can't be "incorrect" or contradicted.


    This allows Linz_H and Linz:H correctly report on the actual
    behavior of their input.



    No, since BOTH have an input that when run will HALT, and both
    report that it will not, both are just wrong.

    Linz_H(Linz_H_Hat, Linz_H_Hat) is claimed to "correctly" return 0, >>>>>> *I never said that you are confused*

    You always claim that your H by its various names is "Correct" to
    return 0 as the input is non-halting because its "correct
    simulation" will never reach a final state.

    I think your brain is turning into mush, or is your pathology
    overloading and trying to reverse the argument.

    Linz_H_Hat(Linz_H_Hat) returns 0 permitting
    Linz_H(Linz_H_Hat, Linz_H_Hat) to correctly return 1.


    But if Linz_H(Linz_H_Hat, Linz_H_Hat) returns 1, which means Halting, >>>>
    Linz_H_Hat has its own embedded_H that returns 0.
    Linz_H_Hat has no access to Linz_H, only to its own embedded copy.

    But embedded_H is an identical copy to Linz_H, so if embedded_H
    returns 0, so does Lin

    Linz_H simply simulates Linz_H_Hat until it terminates.

    Then so must embedded_H, since it is an identical copy, and as you
    have shown before, if H is defined that way, the H_Hat will never
    halt, and thus H, since for this case you said it doesn't abort, will
    also never halt and fail to be a decider.


    We have gone through this many hundreds of times.
    It is the exact same H(D,D) versus H1(D,D) thing.

    Linz_H_Hat now has a pathological relationship to itself
    this frees Linz_H from such a pathological relationship.
    So Linz_H becomes H1, and Linz_H_Hat becomes H.

    Nope, just shows you are not working in a Turing Equivalent system, and
    thus NOTHING you say matters.


    You can make such claims with bluster finding a source that actually
    supports them is a whole different matter.

    It is the case that when embedded_H is a simulating termination analyzer applied to ⟨Ĥ⟩ ⟨Ĥ⟩ that the simulated input cannot possibly terminate normally and must have its simulation aborted.

    It is not the case the Linz:H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ that its input must have its simulation terminated.


    Now, since you are claiming that the embedded_H and Linz_H are
    IDENTICAL machines, but the also produce DIFFERENT results when given
    identical inputs, you have just proven that you are a LIAR.

    *So you are back to rejecting verified facts out-of-hand*
    It is a verified fact that H(D,D) returns 0 and H1(D,D) returns
    1 and the only difference is that H1 does not have a pathological
    relationship to H and it is otherwise identical to H.


    Since youy refuse to provide the verification fact about where the paths
    of H(D,D) and D(D) differ, you don't HAVE a "verified fact".


    The source code and execution trace have been available for a year.
    I have explained this many times the problem seems to be that you simply
    don't believe the facts. You say that a simulation is incorrect yet
    cannot point to the instruction that was simulated incorrectly only
    because the simulation is actually correct.

    You are just proving that you are just a LIAR and an IDIOT.

    What IS verified is that D(D) Halts, so H(D,D) returning 0 is BY
    DEFINITION WRONG and you claim tha tit is right is a verified LIE.


    It depends on how you frame the problem.
    If you frame the problem in that a halt decider must divide up finite
    strings pairs into those that halt when directly executed and those that
    do not, then no single program can do this. A pair of programs might do
    this.

    If you frame the problem in that a halt decider must divide up finite
    stings into those that must have their simulation aborted to prevent
    their infinite execution, then from H's point of view D does not halt.




    --
    Copyright 2023 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 Jul 4 09:27:13 2023
    XPost: comp.theory, sci.logic

    On 7/4/23 12:57 AM, olcott wrote:
    On 7/3/2023 11:06 PM, Richard Damon wrote:
    On 7/3/23 11:56 PM, olcott wrote:
    On 7/3/2023 10:22 PM, Richard Damon wrote:
    On 7/3/23 10:20 PM, olcott wrote:
    On 7/3/2023 4:55 PM, Richard Damon wrote:
    On 7/3/23 5:34 PM, olcott wrote:
    On 7/3/2023 4:17 PM, Richard Damon wrote:
    On 7/3/23 4:22 PM, olcott wrote:
    On 7/3/2023 2:58 PM, Richard Damon wrote:
    On 7/3/23 2:48 PM, olcott wrote:
    On 7/3/2023 1:25 PM, Richard Damon wrote:
    On 7/3/23 1:57 PM, olcott wrote:
    On 7/3/2023 11:26 AM, Richard Damon wrote:
    On 7/3/23 12:11 PM, olcott wrote:
    On 7/3/2023 11:01 AM, Richard Damon wrote:
    On 7/3/23 11:56 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote:
    On 7/3/23 10:45 AM, olcott wrote:
    On 7/3/2023 9:24 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 7/3/23 9:47 AM, olcott wrote:
    On 7/3/2023 8:14 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>> On 7/2/23 10:48 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>> On 7/2/2023 9:41 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 7/2/23 10:01 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 7/2/2023 8:40 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 7/2/23 8:45 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> A single H can consistently correctly >>>>>>>>>>>>>>>>>>>>>>>>>>> determine whether or not its input >>>>>>>>>>>>>>>>>>>>>>>>>>> is pathological relative to itself. When >>>>>>>>>>>>>>>>>>>>>>>>>>> H(D,D) is invoked in
    decidability decider mode determines that D >>>>>>>>>>>>>>>>>>>>>>>>>>> is pathological relative to >>>>>>>>>>>>>>>>>>>>>>>>>>> itself this enables a batch file to invoke >>>>>>>>>>>>>>>>>>>>>>>>>>> H1(D,D) to get the actual >>>>>>>>>>>>>>>>>>>>>>>>>>> behavior of the directly executed D(D). H1 is >>>>>>>>>>>>>>>>>>>>>>>>>>> identical to H except for >>>>>>>>>>>>>>>>>>>>>>>>>>> the pathological relationship to H. >>>>>>>>>>>>>>>>>>>>>>>>>>>


    And does an input D that uses this FULL >>>>>>>>>>>>>>>>>>>>>>>>>> algorithm give your algorithm problems? >>>>>>>>>>>>>>>>>>>>>>>>>>
    Since H(D,D) will (apparently) determine that >>>>>>>>>>>>>>>>>>>>>>>>>> the input is pathological, and thus defer to >>>>>>>>>>>>>>>>>>>>>>>>>> H1(D,D), then when we actually run D, >>>>>>>>>>>>>>>>>>>>>>>>>> appearently it will get that same answer from >>>>>>>>>>>>>>>>>>>>>>>>>> H1 and do the opposite of it, and thus H1 will >>>>>>>>>>>>>>>>>>>>>>>>>> be wrong.

    Remember, the "Pathological" program is built >>>>>>>>>>>>>>>>>>>>>>>>>> on a copy of the ACTUAL program that you ask >>>>>>>>>>>>>>>>>>>>>>>>>> to decide on it, including ALL of its >>>>>>>>>>>>>>>>>>>>>>>>>> "tricks", including things like this "batch >>>>>>>>>>>>>>>>>>>>>>>>>> processing".

    You seem to be assuming that there is some >>>>>>>>>>>>>>>>>>>>>>>>>> "Operationg System" outside the Decider - >>>>>>>>>>>>>>>>>>>>>>>>>> Input structure, but there isn't, at least not >>>>>>>>>>>>>>>>>>>>>>>>>> one that can affect the answer of the problem. >>>>>>>>>>>>>>>>>>>>>>>>>
    I spent 12 hours a day for the last 10 days >>>>>>>>>>>>>>>>>>>>>>>>> getting the copy the input
    working. When H(D,D) (in decidability decider >>>>>>>>>>>>>>>>>>>>>>>>> mode) detects that its
    input is in the well defined set of >>>>>>>>>>>>>>>>>>>>>>>>> pathological inputs it returns 0 >>>>>>>>>>>>>>>>>>>>>>>>> indicating that its input is undecidable. The >>>>>>>>>>>>>>>>>>>>>>>>> batch file that invoked H
    then knows to invoke H1(D,D) to correctly >>>>>>>>>>>>>>>>>>>>>>>>> report that D(D) halts.

    This solution does seem to work correctly on >>>>>>>>>>>>>>>>>>>>>>>>> every conventional proof in
    every textbook.


    So, did you make your "conventional proof" >>>>>>>>>>>>>>>>>>>>>>>> template actually use a copy of your ACTUAL >>>>>>>>>>>>>>>>>>>>>>>> decider (which seems to be your "batch file" not >>>>>>>>>>>>>>>>>>>>>>>> the C funciton H), or are you just admitting >>>>>>>>>>>>>>>>>>>>>>>> that you wasted 120 hours looking at the wrong >>>>>>>>>>>>>>>>>>>>>>>> thing because you have made yourself >>>>>>>>>>>>>>>>>>>>>>>> intentionally ignorant of the subject so you >>>>>>>>>>>>>>>>>>>>>>>> don't understand what you are trying to do. >>>>>>>>>>>>>>>>>>>>>>>
    New_D copies its input and simulates its input >>>>>>>>>>>>>>>>>>>>>>> with its input.
    It never sees New_H.


    Why not? Since New_H is the thing that is >>>>>>>>>>>>>>>>>>>>>> considered the "Correct Halt Decider", New_D needs >>>>>>>>>>>>>>>>>>>>>> to be built on it.


    New_H is embedded within New_D (as its middle >>>>>>>>>>>>>>>>>>>>> states) just the
    way it is supposed to be. The question is: Does >>>>>>>>>>>>>>>>>>>>> New_H(New_H) halt?

    The only difference at the source code level is: >>>>>>>>>>>>>>>>>>>>> (a) New_H copies its input, thus takes one param. >>>>>>>>>>>>>>>>>>>>> (b) New_H has an infinite loop at its accept state. >>>>>>>>>>>>>>>>>>>>
    So, how is New_H a halt decider then?

    typo
    The only difference at the source code level is: >>>>>>>>>>>>>>>>>>> (a) New_D copies its input, thus takes one param. >>>>>>>>>>>>>>>>>>> (b) New_D has an infinite loop at its accept state. >>>>>>>>>>>>>>>>>>> Other than that (at the source-code level) New_D is >>>>>>>>>>>>>>>>>>> exactly New_H



    But New_D needs to call New_H,

    Not in the Peter Linz proof:
    https://www.liarparadox.org/Linz_Proof.pdf

    In the Linz proof a copy of H is directly embedded >>>>>>>>>>>>>>>>> within Ĥ at this state: Ĥq0 Wm Wm
    The original H remains unchanged.

    The halting problem is about undecidable inputs, it is >>>>>>>>>>>>>>>>> not about
    inserting bugs into a halt decider to make it cease to >>>>>>>>>>>>>>>>> function.



    Right, and in Linz, H is the decider that is claimed to >>>>>>>>>>>>>>>> give the right answer.

    That isn't 'H' in your system, but the script that >>>>>>>>>>>>>>>> decides whether to use H or H1.

    Your error is in calling the wrong thing 'H'

    You are just showing you are lying by using the wrong >>>>>>>>>>>>>>>> name for things.

    You are using double-talk in a lame attempt to show that >>>>>>>>>>>>>>> Linz H cannot correctly determine the halt status of Linz Ĥ. >>>>>>>>>>>>>>>

    So you agree with the Theorem.

    No 'Linz H' can exist that correctly decides the halt >>>>>>>>>>>>>> status of Linz Ĥ applied to the description of Linz Ĥ. >>>>>>>>>>>>>>
    That is EXACTLY the consequence of the Halting Theorem. >>>>>>>>>>>>>>

    Please show an ACTUAL 'Linz H' that correctly gets the >>>>>>>>>>>>>> results of the 'Linz Ĥ' built on it. You keep on changing >>>>>>>>>>>>>> H and trying to use the old Ĥ which just fails to meet the >>>>>>>>>>>>>> requirement of the proof, likely because you just don't >>>>>>>>>>>>>> understand the theory involved.

    It took me two years to figure out a clean way to copy the >>>>>>>>>>>>> input to
    Linz_H_Hat and not have the system crash. Relative to >>>>>>>>>>>>> Linz_H_Hat
    Linz_H is H1. Now Linz_H_Hat only contradicts itself. >>>>>>>>>>>>>

    So, you are admitting that you actually can't do what is >>>>>>>>>>>> required?

    Copying the input should be trivial,

    The relative addressing of the x86 language causes all function >>>>>>>>>>> calls to call the wrong address.

    Only because you aren't interpreting the input properly, but >>>>>>>>>> in a non-Turing Complete manner.

    As I said, the input description should be a chunck of code in >>>>>>>>>> a virtual address space with a header that tells where that >>>>>>>>>> code is supposed to be considered to be located at.


    as the input should be a representation that packages a full >>>>>>>>>>>> program in its own virtual environment, so a simple bit by >>>>>>>>>>>> bit copy to empty ram will work. Your problem is that you >>>>>>>>>>>> don't put the input into its own virtual address space, so >>>>>>>>>>>> you have pathological interactions.

    Linz_H_Hat must be built on the exact code base that is >>>>>>>>>>>> deciding on it, in this case H, since you just said it >>>>>>>>>>>> isn't, your proof is invalid.


    Linz_Hat <is> Linz_H that takes one param  and copies it >>>>>>>>>>> instead of
    two params and has an infinite loop at its accept state.

    So, Two things that are different are exactly the same?


    It exactly matches the Linz spec.

    You don't seem to understand what you are doing.

    Linz_H_Hat (not Linz_Hat) is a Turing Machine with a defined >>>>>>>>>> behavior. That behavior is a function of its input, but hasn't >>>>>>>>>> been assigned any "meaning".

    Linz_H is a Turing Machine (if it actually can exist) that has >>>>>>>>>> a defined meaning/requirement for its final states. Linz_H, to >>>>>>>>>> meet its requirements, MUST go to Qy if the input represents a >>>>>>>>>> Halting Computation, and MUST go to Qn if the input represents >>>>>>>>>> a non-halting computation.

    Since Linz_H has actual requirements, a claimed implementation >>>>>>>>>> of it can be checked to see if it actually meets the
    requirements, and perhaps we can determine if it is possible >>>>>>>>>> to meet them.


    Note, Linz_H_Hat CAN'T "Contradict" itself, as doesn't >>>>>>>>>>>> generate any truth values, only behavior. You are just >>>>>>>>>>>> showing that you don't understand the basics of the
    requirements, and seem to think that "close" is good enough >>>>>>>>>>>> for proofs.

    Linz_H_Hat(Linz_H_Hat) returns 0.

    Actually no. Linz_H_Hat(Linz_H_Hat) halts at state Qn, which >>>>>>>>>> has NO
    defined meaning for Linz_H_Hat as it isn't defined to be a >>>>>>>>>> decider.

    Linz_H and Linz_H_Hat are C functions.
    Linz:H and Linz:Ĥ are Turing machines.

    So, inventing new terminology without introduction, thus showing >>>>>>>> you are being intentionally deceptive.


    Linz_H and Linz:H are both directly embedded within a copy of >>>>>>>>> Linz_H_Hat and Linz:Ĥ thus a return value of 0 or a transition >>>>>>>>> to Ĥ.qn still means not halting.

    No, because Linz_H_Hat / Linz:Ĥ are not "Halt Deciders" so there >>>>>>>> return value has no meaning.

    Ĥ has no meaning, so it can't be "incorrect" or contradicted. >>>>>>>>

    This allows Linz_H and Linz:H correctly report on the actual >>>>>>>>> behavior of their input.



    No, since BOTH have an input that when run will HALT, and both >>>>>>>> report that it will not, both are just wrong.

    Linz_H(Linz_H_Hat, Linz_H_Hat) is claimed to "correctly" return 0, >>>>>>> *I never said that you are confused*

    You always claim that your H by its various names is "Correct" to
    return 0 as the input is non-halting because its "correct
    simulation" will never reach a final state.

    I think your brain is turning into mush, or is your pathology
    overloading and trying to reverse the argument.

    Linz_H_Hat(Linz_H_Hat) returns 0 permitting
    Linz_H(Linz_H_Hat, Linz_H_Hat) to correctly return 1.


    But if Linz_H(Linz_H_Hat, Linz_H_Hat) returns 1, which means Halting, >>>>>
    Linz_H_Hat has its own embedded_H that returns 0.
    Linz_H_Hat has no access to Linz_H, only to its own embedded copy.

    But embedded_H is an identical copy to Linz_H, so if embedded_H
    returns 0, so does Lin

    Linz_H simply simulates Linz_H_Hat until it terminates.

    Then so must embedded_H, since it is an identical copy, and as you
    have shown before, if H is defined that way, the H_Hat will never
    halt, and thus H, since for this case you said it doesn't abort,
    will also never halt and fail to be a decider.


    We have gone through this many hundreds of times.
    It is the exact same H(D,D) versus H1(D,D) thing.

    Linz_H_Hat now has a pathological relationship to itself
    this frees Linz_H from such a pathological relationship.
    So Linz_H becomes H1, and Linz_H_Hat becomes H.

    Nope, just shows you are not working in a Turing Equivalent system,
    and thus NOTHING you say matters.


    You can make such claims with bluster finding a source that actually
    supports them is a whole different matter.

    No, you are just showing that you believe Russell's Teapot actually
    exists. YOU are the one making claims, so YOU are the one that needs to
    make a actual proof of correctness, and show the error in the counter
    claims.

    It is a PROVEN fact that two computation machines with the exact same
    algorithm and the exact same input will always produce the same result.

    You are claiming differently, WITHOUT PROOF, so you are shown to be a LIAR.

    Either H and H1 are claimed to be the same machine, or they are not. If
    they are the same machine, they need to give the same answer, or they
    are not, and thus H1 getting the right answer to the H^ built on H
    doesn't matter.


    It is the case that when embedded_H is a simulating termination analyzer applied to ⟨Ĥ⟩ ⟨Ĥ⟩ that the simulated input cannot possibly terminate
    normally and must have its simulation aborted.

    So?


    It is not the case the Linz:H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ that its input must
    have its simulation terminated.

    Thus Linz:H and embedded_H aren't the same machine, as REQUIRED, thus
    showing that you hav just been LYING for decades.



    Now, since you are claiming that the embedded_H and Linz_H are
    IDENTICAL machines, but the also produce DIFFERENT results when
    given identical inputs, you have just proven that you are a LIAR.

    *So you are back to rejecting verified facts out-of-hand*
    It is a verified fact that H(D,D) returns 0 and H1(D,D) returns
    1 and the only difference is that H1 does not have a pathological
    relationship to H and it is otherwise identical to H.


    Since youy refuse to provide the verification fact about where the
    paths of H(D,D) and D(D) differ, you don't HAVE a "verified fact".


    The source code and execution trace have been available for a year.
    I have explained this many times the problem seems to be that you simply don't believe the facts. You say that a simulation is incorrect yet
    cannot point to the instruction that was simulated incorrectly only
    because the simulation is actually correct.

    No, YOU LIE. The "Call H" instruction has been simulated incorrectly (or
    not simulated at all an false presumptions about what it does used).


    You are just proving that you are just a LIAR and an IDIOT.

    What IS verified is that D(D) Halts, so H(D,D) returning 0 is BY
    DEFINITION WRONG and you claim tha tit is right is a verified LIE.


    It depends on how you frame the problem.
    If you frame the problem in that a halt decider must divide up finite
    strings pairs into those that halt when directly executed and those that
    do not, then no single program can do this. A pair of programs might do
    this.

    So, you agree with the Halting Theorem, as that it is the precise
    problem being asked about.


    If you frame the problem in that a halt decider must divide up finite
    stings into those that must have their simulation aborted to prevent
    their infinite execution, then from H's point of view D does not halt.


    So, you are admitting to using a Strawman, and nothing you say applies
    to the ACTUAL Halting Problem.

    You have maybe shown that POOP might be decidable, it at least can't use
    the simple pathological example to show it, but POOP isn't about Halting
    but partial simulation, so who cares about it.

    This shows your mental instability as we don't care about what H sees,
    which is just something of its imagination, we care about the reality of
    what D actually does. Just like we care about what is ACTUALLY true,
    verses what you think must be true without actually trying to prove it logically.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Richard Damon on Tue Jul 4 16:52:43 2023
    XPost: comp.theory, sci.logic

    On 7/4/2023 8:27 AM, Richard Damon wrote:
    On 7/4/23 12:57 AM, olcott wrote:
    On 7/3/2023 11:06 PM, Richard Damon wrote:
    On 7/3/23 11:56 PM, olcott wrote:
    On 7/3/2023 10:22 PM, Richard Damon wrote:
    On 7/3/23 10:20 PM, olcott wrote:
    On 7/3/2023 4:55 PM, Richard Damon wrote:
    On 7/3/23 5:34 PM, olcott wrote:
    On 7/3/2023 4:17 PM, Richard Damon wrote:
    On 7/3/23 4:22 PM, olcott wrote:
    On 7/3/2023 2:58 PM, Richard Damon wrote:
    On 7/3/23 2:48 PM, olcott wrote:
    On 7/3/2023 1:25 PM, Richard Damon wrote:
    On 7/3/23 1:57 PM, olcott wrote:
    On 7/3/2023 11:26 AM, Richard Damon wrote:
    On 7/3/23 12:11 PM, olcott wrote:
    On 7/3/2023 11:01 AM, Richard Damon wrote:
    On 7/3/23 11:56 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>> On 7/3/23 10:45 AM, olcott wrote:
    On 7/3/2023 9:24 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>> On 7/3/23 9:47 AM, olcott wrote:
    On 7/3/2023 8:14 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>> On 7/2/23 10:48 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 7/2/2023 9:41 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 7/2/23 10:01 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 7/2/2023 8:40 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/2/23 8:45 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> A single H can consistently correctly >>>>>>>>>>>>>>>>>>>>>>>>>>>> determine whether or not its input >>>>>>>>>>>>>>>>>>>>>>>>>>>> is pathological relative to itself. When >>>>>>>>>>>>>>>>>>>>>>>>>>>> H(D,D) is invoked in
    decidability decider mode determines that D >>>>>>>>>>>>>>>>>>>>>>>>>>>> is pathological relative to >>>>>>>>>>>>>>>>>>>>>>>>>>>> itself this enables a batch file to invoke >>>>>>>>>>>>>>>>>>>>>>>>>>>> H1(D,D) to get the actual >>>>>>>>>>>>>>>>>>>>>>>>>>>> behavior of the directly executed D(D). H1 >>>>>>>>>>>>>>>>>>>>>>>>>>>> is identical to H except for >>>>>>>>>>>>>>>>>>>>>>>>>>>> the pathological relationship to H. >>>>>>>>>>>>>>>>>>>>>>>>>>>>


    And does an input D that uses this FULL >>>>>>>>>>>>>>>>>>>>>>>>>>> algorithm give your algorithm problems? >>>>>>>>>>>>>>>>>>>>>>>>>>>
    Since H(D,D) will (apparently) determine that >>>>>>>>>>>>>>>>>>>>>>>>>>> the input is pathological, and thus defer to >>>>>>>>>>>>>>>>>>>>>>>>>>> H1(D,D), then when we actually run D, >>>>>>>>>>>>>>>>>>>>>>>>>>> appearently it will get that same answer from >>>>>>>>>>>>>>>>>>>>>>>>>>> H1 and do the opposite of it, and thus H1 >>>>>>>>>>>>>>>>>>>>>>>>>>> will be wrong.

    Remember, the "Pathological" program is built >>>>>>>>>>>>>>>>>>>>>>>>>>> on a copy of the ACTUAL program that you ask >>>>>>>>>>>>>>>>>>>>>>>>>>> to decide on it, including ALL of its >>>>>>>>>>>>>>>>>>>>>>>>>>> "tricks", including things like this "batch >>>>>>>>>>>>>>>>>>>>>>>>>>> processing".

    You seem to be assuming that there is some >>>>>>>>>>>>>>>>>>>>>>>>>>> "Operationg System" outside the Decider - >>>>>>>>>>>>>>>>>>>>>>>>>>> Input structure, but there isn't, at least >>>>>>>>>>>>>>>>>>>>>>>>>>> not one that can affect the answer of the >>>>>>>>>>>>>>>>>>>>>>>>>>> problem.

    I spent 12 hours a day for the last 10 days >>>>>>>>>>>>>>>>>>>>>>>>>> getting the copy the input >>>>>>>>>>>>>>>>>>>>>>>>>> working. When H(D,D) (in decidability decider >>>>>>>>>>>>>>>>>>>>>>>>>> mode) detects that its
    input is in the well defined set of >>>>>>>>>>>>>>>>>>>>>>>>>> pathological inputs it returns 0 >>>>>>>>>>>>>>>>>>>>>>>>>> indicating that its input is undecidable. The >>>>>>>>>>>>>>>>>>>>>>>>>> batch file that invoked H
    then knows to invoke H1(D,D) to correctly >>>>>>>>>>>>>>>>>>>>>>>>>> report that D(D) halts.

    This solution does seem to work correctly on >>>>>>>>>>>>>>>>>>>>>>>>>> every conventional proof in >>>>>>>>>>>>>>>>>>>>>>>>>> every textbook.


    So, did you make your "conventional proof" >>>>>>>>>>>>>>>>>>>>>>>>> template actually use a copy of your ACTUAL >>>>>>>>>>>>>>>>>>>>>>>>> decider (which seems to be your "batch file" >>>>>>>>>>>>>>>>>>>>>>>>> not the C funciton H), or are you just >>>>>>>>>>>>>>>>>>>>>>>>> admitting that you wasted 120 hours looking at >>>>>>>>>>>>>>>>>>>>>>>>> the wrong thing because you have made yourself >>>>>>>>>>>>>>>>>>>>>>>>> intentionally ignorant of the subject so you >>>>>>>>>>>>>>>>>>>>>>>>> don't understand what you are trying to do. >>>>>>>>>>>>>>>>>>>>>>>>
    New_D copies its input and simulates its input >>>>>>>>>>>>>>>>>>>>>>>> with its input.
    It never sees New_H.


    Why not? Since New_H is the thing that is >>>>>>>>>>>>>>>>>>>>>>> considered the "Correct Halt Decider", New_D >>>>>>>>>>>>>>>>>>>>>>> needs to be built on it.


    New_H is embedded within New_D (as its middle >>>>>>>>>>>>>>>>>>>>>> states) just the
    way it is supposed to be. The question is: Does >>>>>>>>>>>>>>>>>>>>>> New_H(New_H) halt?

    The only difference at the source code level is: >>>>>>>>>>>>>>>>>>>>>> (a) New_H copies its input, thus takes one param. >>>>>>>>>>>>>>>>>>>>>> (b) New_H has an infinite loop at its accept state. >>>>>>>>>>>>>>>>>>>>>
    So, how is New_H a halt decider then? >>>>>>>>>>>>>>>>>>>>
    typo
    The only difference at the source code level is: >>>>>>>>>>>>>>>>>>>> (a) New_D copies its input, thus takes one param. >>>>>>>>>>>>>>>>>>>> (b) New_D has an infinite loop at its accept state. >>>>>>>>>>>>>>>>>>>> Other than that (at the source-code level) New_D is >>>>>>>>>>>>>>>>>>>> exactly New_H



    But New_D needs to call New_H,

    Not in the Peter Linz proof:
    https://www.liarparadox.org/Linz_Proof.pdf >>>>>>>>>>>>>>>>>>
    In the Linz proof a copy of H is directly embedded >>>>>>>>>>>>>>>>>> within Ĥ at this state: Ĥq0 Wm Wm
    The original H remains unchanged.

    The halting problem is about undecidable inputs, it is >>>>>>>>>>>>>>>>>> not about
    inserting bugs into a halt decider to make it cease to >>>>>>>>>>>>>>>>>> function.



    Right, and in Linz, H is the decider that is claimed to >>>>>>>>>>>>>>>>> give the right answer.

    That isn't 'H' in your system, but the script that >>>>>>>>>>>>>>>>> decides whether to use H or H1.

    Your error is in calling the wrong thing 'H' >>>>>>>>>>>>>>>>>
    You are just showing you are lying by using the wrong >>>>>>>>>>>>>>>>> name for things.

    You are using double-talk in a lame attempt to show that >>>>>>>>>>>>>>>> Linz H cannot correctly determine the halt status of >>>>>>>>>>>>>>>> Linz Ĥ.


    So you agree with the Theorem.

    No 'Linz H' can exist that correctly decides the halt >>>>>>>>>>>>>>> status of Linz Ĥ applied to the description of Linz Ĥ. >>>>>>>>>>>>>>>
    That is EXACTLY the consequence of the Halting Theorem. >>>>>>>>>>>>>>>

    Please show an ACTUAL 'Linz H' that correctly gets the >>>>>>>>>>>>>>> results of the 'Linz Ĥ' built on it. You keep on changing >>>>>>>>>>>>>>> H and trying to use the old Ĥ which just fails to meet >>>>>>>>>>>>>>> the requirement of the proof, likely because you just >>>>>>>>>>>>>>> don't understand the theory involved.

    It took me two years to figure out a clean way to copy the >>>>>>>>>>>>>> input to
    Linz_H_Hat and not have the system crash. Relative to >>>>>>>>>>>>>> Linz_H_Hat
    Linz_H is H1. Now Linz_H_Hat only contradicts itself. >>>>>>>>>>>>>>

    So, you are admitting that you actually can't do what is >>>>>>>>>>>>> required?

    Copying the input should be trivial,

    The relative addressing of the x86 language causes all function >>>>>>>>>>>> calls to call the wrong address.

    Only because you aren't interpreting the input properly, but >>>>>>>>>>> in a non-Turing Complete manner.

    As I said, the input description should be a chunck of code >>>>>>>>>>> in a virtual address space with a header that tells where >>>>>>>>>>> that code is supposed to be considered to be located at. >>>>>>>>>>>

    as the input should be a representation that packages a >>>>>>>>>>>>> full program in its own virtual environment, so a simple >>>>>>>>>>>>> bit by bit copy to empty ram will work. Your problem is >>>>>>>>>>>>> that you don't put the input into its own virtual address >>>>>>>>>>>>> space, so you have pathological interactions.

    Linz_H_Hat must be built on the exact code base that is >>>>>>>>>>>>> deciding on it, in this case H, since you just said it >>>>>>>>>>>>> isn't, your proof is invalid.


    Linz_Hat <is> Linz_H that takes one param  and copies it >>>>>>>>>>>> instead of
    two params and has an infinite loop at its accept state. >>>>>>>>>>>
    So, Two things that are different are exactly the same?


    It exactly matches the Linz spec.

    You don't seem to understand what you are doing.

    Linz_H_Hat (not Linz_Hat) is a Turing Machine with a defined >>>>>>>>>>> behavior. That behavior is a function of its input, but
    hasn't been assigned any "meaning".

    Linz_H is a Turing Machine (if it actually can exist) that >>>>>>>>>>> has a defined meaning/requirement for its final states.
    Linz_H, to meet its requirements, MUST go to Qy if the input >>>>>>>>>>> represents a Halting Computation, and MUST go to Qn if the >>>>>>>>>>> input represents a non-halting computation.

    Since Linz_H has actual requirements, a claimed
    implementation of it can be checked to see if it actually >>>>>>>>>>> meets the requirements, and perhaps we can determine if it is >>>>>>>>>>> possible to meet them.


    Note, Linz_H_Hat CAN'T "Contradict" itself, as doesn't >>>>>>>>>>>>> generate any truth values, only behavior. You are just >>>>>>>>>>>>> showing that you don't understand the basics of the
    requirements, and seem to think that "close" is good enough >>>>>>>>>>>>> for proofs.

    Linz_H_Hat(Linz_H_Hat) returns 0.

    Actually no. Linz_H_Hat(Linz_H_Hat) halts at state Qn, >>>>>>>>>>> which has NO
    defined meaning for Linz_H_Hat as it isn't defined to be a >>>>>>>>>>> decider.

    Linz_H and Linz_H_Hat are C functions.
    Linz:H and Linz:Ĥ are Turing machines.

    So, inventing new terminology without introduction, thus
    showing you are being intentionally deceptive.


    Linz_H and Linz:H are both directly embedded within a copy of >>>>>>>>>> Linz_H_Hat and Linz:Ĥ thus a return value of 0 or a transition >>>>>>>>>> to Ĥ.qn still means not halting.

    No, because Linz_H_Hat / Linz:Ĥ are not "Halt Deciders" so
    there return value has no meaning.

    Ĥ has no meaning, so it can't be "incorrect" or contradicted. >>>>>>>>>

    This allows Linz_H and Linz:H correctly report on the actual >>>>>>>>>> behavior of their input.



    No, since BOTH have an input that when run will HALT, and both >>>>>>>>> report that it will not, both are just wrong.

    Linz_H(Linz_H_Hat, Linz_H_Hat) is claimed to "correctly" return 0, >>>>>>>> *I never said that you are confused*

    You always claim that your H by its various names is "Correct" to >>>>>>> return 0 as the input is non-halting because its "correct
    simulation" will never reach a final state.

    I think your brain is turning into mush, or is your pathology
    overloading and trying to reverse the argument.

    Linz_H_Hat(Linz_H_Hat) returns 0 permitting
    Linz_H(Linz_H_Hat, Linz_H_Hat) to correctly return 1.


    But if Linz_H(Linz_H_Hat, Linz_H_Hat) returns 1, which means
    Halting,

    Linz_H_Hat has its own embedded_H that returns 0.
    Linz_H_Hat has no access to Linz_H, only to its own embedded copy.

    But embedded_H is an identical copy to Linz_H, so if embedded_H
    returns 0, so does Lin

    Linz_H simply simulates Linz_H_Hat until it terminates.

    Then so must embedded_H, since it is an identical copy, and as you
    have shown before, if H is defined that way, the H_Hat will never
    halt, and thus H, since for this case you said it doesn't abort,
    will also never halt and fail to be a decider.


    We have gone through this many hundreds of times.
    It is the exact same H(D,D) versus H1(D,D) thing.

    Linz_H_Hat now has a pathological relationship to itself
    this frees Linz_H from such a pathological relationship.
    So Linz_H becomes H1, and Linz_H_Hat becomes H.

    Nope, just shows you are not working in a Turing Equivalent system,
    and thus NOTHING you say matters.


    You can make such claims with bluster finding a source that actually
    supports them is a whole different matter.

    No, you are just showing that you believe Russell's Teapot actually
    exists. YOU are the one making claims, so YOU are the one that needs to
    make a actual proof of correctness, and show the error in the counter
    claims.


    If you believe that I am incorrect you need much more than your own
    presumption as a basis for an actual rebuttal. You might not have
    much more than this mere presumption.

    It is a PROVEN fact that two computation machines with the exact same algorithm and the exact same input will always produce the same result.

    You are claiming differently, WITHOUT PROOF, so you are shown to be a LIAR.


    H1(D,D) and H(D,D) have different execution traces because D calls H and
    D does not call H1. A not very bright software engineer could understand
    this.

    Either H and H1 are claimed to be the same machine, or they are not. If
    they are the same machine, they need to give the same answer, or they
    are not, and thus H1 getting the right answer to the H^ built on H
    doesn't matter.


    It is the case that when embedded_H is a simulating termination analyzer
    applied to ⟨Ĥ⟩ ⟨Ĥ⟩ that the simulated input cannot possibly terminate
    normally and must have its simulation aborted.

    So?


    It is not the case the Linz:H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ that its input must
    have its simulation terminated.

    Thus Linz:H and embedded_H aren't the same machine, as REQUIRED, thus
    showing that you hav just been LYING for decades.

    It is a simple execution trace that even a bright high school student
    can understand now that I have shown it at the C source code level.



    Now, since you are claiming that the embedded_H and Linz_H are
    IDENTICAL machines, but the also produce DIFFERENT results when
    given identical inputs, you have just proven that you are a LIAR.

    *So you are back to rejecting verified facts out-of-hand*
    It is a verified fact that H(D,D) returns 0 and H1(D,D) returns
    1 and the only difference is that H1 does not have a pathological
    relationship to H and it is otherwise identical to H.


    Since youy refuse to provide the verification fact about where the
    paths of H(D,D) and D(D) differ, you don't HAVE a "verified fact".


    The source code and execution trace have been available for a year.
    I have explained this many times the problem seems to be that you simply
    don't believe the facts. You say that a simulation is incorrect yet
    cannot point to the instruction that was simulated incorrectly only
    because the simulation is actually correct.

    No, YOU LIE. The "Call H" instruction has been simulated incorrectly (or
    not simulated at all an false presumptions about what it does used).


    You are just proving that you are just a LIAR and an IDIOT.

    What IS verified is that D(D) Halts, so H(D,D) returning 0 is BY
    DEFINITION WRONG and you claim tha tit is right is a verified LIE.


    It depends on how you frame the problem.
    If you frame the problem in that a halt decider must divide up finite
    strings pairs into those that halt when directly executed and those that
    do not, then no single program can do this. A pair of programs might do
    this.

    So, you agree with the Halting Theorem, as that it is the precise
    problem being asked about.


    If you frame the problem in that a halt decider must divide up finite
    stings into those that must have their simulation aborted to prevent
    their infinite execution, then from H's point of view D does not halt.


    So, you are admitting to using a Strawman, and nothing you say applies
    to the ACTUAL Halting Problem.

    You have maybe shown that POOP might be decidable, it at least can't use
    the simple pathological example to show it, but POOP isn't about Halting
    but partial simulation, so who cares about it.

    This shows your mental instability as we don't care about what H sees,
    which is just something of its imagination, we care about the reality of
    what D actually does. Just like we care about what is ACTUALLY true,
    verses what you think must be true without actually trying to prove it logically.

    It turns out that Linz_H(Linz_H_Hat, Linz_H_Hat) == 1
    because Linz_H_Hat(Linz_H_Hat) == 0

    This translates into Linz:H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly
    transitions to Linz:H.qy because Linz:Ĥ applied to ⟨Ĥ⟩
    transitions to Linz:Ĥ.qn

    So I have overcome the issue of H(D,D) reporting non-halting and
    the directly executed D(D) then halting in two different ways:

    (1) Linz_H(Linz_H_Hat, Linz_H_Hat) reports halting and
    Linz_H_Hat(Linz_H_Hat) halts.

    (2) With the three value return of H(D,D) H only reports halting
    when its directly executed input actually halts and seems to
    defeat Rice by separately reporting all conventional halting
    problem proof pathological inputs.


    --
    Copyright 2023 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 Jul 4 19:00:34 2023
    XPost: comp.theory, sci.logic

    On 7/4/23 5:52 PM, olcott wrote:
    On 7/4/2023 8:27 AM, Richard Damon wrote:
    On 7/4/23 12:57 AM, olcott wrote:
    On 7/3/2023 11:06 PM, Richard Damon wrote:
    On 7/3/23 11:56 PM, olcott wrote:
    On 7/3/2023 10:22 PM, Richard Damon wrote:
    On 7/3/23 10:20 PM, olcott wrote:
    On 7/3/2023 4:55 PM, Richard Damon wrote:
    On 7/3/23 5:34 PM, olcott wrote:
    On 7/3/2023 4:17 PM, Richard Damon wrote:
    On 7/3/23 4:22 PM, olcott wrote:
    On 7/3/2023 2:58 PM, Richard Damon wrote:
    On 7/3/23 2:48 PM, olcott wrote:
    On 7/3/2023 1:25 PM, Richard Damon wrote:
    On 7/3/23 1:57 PM, olcott wrote:
    On 7/3/2023 11:26 AM, Richard Damon wrote:
    On 7/3/23 12:11 PM, olcott wrote:
    On 7/3/2023 11:01 AM, Richard Damon wrote:
    On 7/3/23 11:56 AM, olcott wrote:
    On 7/3/2023 10:35 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 7/3/23 10:45 AM, olcott wrote:
    On 7/3/2023 9:24 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>> On 7/3/23 9:47 AM, olcott wrote:
    On 7/3/2023 8:14 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 7/2/23 10:48 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 7/2/2023 9:41 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 7/2/23 10:01 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/2/2023 8:40 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/2/23 8:45 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> A single H can consistently correctly >>>>>>>>>>>>>>>>>>>>>>>>>>>>> determine whether or not its input >>>>>>>>>>>>>>>>>>>>>>>>>>>>> is pathological relative to itself. When >>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(D,D) is invoked in >>>>>>>>>>>>>>>>>>>>>>>>>>>>> decidability decider mode determines that D >>>>>>>>>>>>>>>>>>>>>>>>>>>>> is pathological relative to >>>>>>>>>>>>>>>>>>>>>>>>>>>>> itself this enables a batch file to invoke >>>>>>>>>>>>>>>>>>>>>>>>>>>>> H1(D,D) to get the actual >>>>>>>>>>>>>>>>>>>>>>>>>>>>> behavior of the directly executed D(D). H1 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> is identical to H except for >>>>>>>>>>>>>>>>>>>>>>>>>>>>> the pathological relationship to H. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>


    And does an input D that uses this FULL >>>>>>>>>>>>>>>>>>>>>>>>>>>> algorithm give your algorithm problems? >>>>>>>>>>>>>>>>>>>>>>>>>>>>
    Since H(D,D) will (apparently) determine >>>>>>>>>>>>>>>>>>>>>>>>>>>> that the input is pathological, and thus >>>>>>>>>>>>>>>>>>>>>>>>>>>> defer to H1(D,D), then when we actually run >>>>>>>>>>>>>>>>>>>>>>>>>>>> D, appearently it will get that same answer >>>>>>>>>>>>>>>>>>>>>>>>>>>> from H1 and do the opposite of it, and thus >>>>>>>>>>>>>>>>>>>>>>>>>>>> H1 will be wrong.

    Remember, the "Pathological" program is >>>>>>>>>>>>>>>>>>>>>>>>>>>> built on a copy of the ACTUAL program that >>>>>>>>>>>>>>>>>>>>>>>>>>>> you ask to decide on it, including ALL of >>>>>>>>>>>>>>>>>>>>>>>>>>>> its "tricks", including things like this >>>>>>>>>>>>>>>>>>>>>>>>>>>> "batch processing".

    You seem to be assuming that there is some >>>>>>>>>>>>>>>>>>>>>>>>>>>> "Operationg System" outside the Decider - >>>>>>>>>>>>>>>>>>>>>>>>>>>> Input structure, but there isn't, at least >>>>>>>>>>>>>>>>>>>>>>>>>>>> not one that can affect the answer of the >>>>>>>>>>>>>>>>>>>>>>>>>>>> problem.

    I spent 12 hours a day for the last 10 days >>>>>>>>>>>>>>>>>>>>>>>>>>> getting the copy the input >>>>>>>>>>>>>>>>>>>>>>>>>>> working. When H(D,D) (in decidability decider >>>>>>>>>>>>>>>>>>>>>>>>>>> mode) detects that its
    input is in the well defined set of >>>>>>>>>>>>>>>>>>>>>>>>>>> pathological inputs it returns 0 >>>>>>>>>>>>>>>>>>>>>>>>>>> indicating that its input is undecidable. The >>>>>>>>>>>>>>>>>>>>>>>>>>> batch file that invoked H >>>>>>>>>>>>>>>>>>>>>>>>>>> then knows to invoke H1(D,D) to correctly >>>>>>>>>>>>>>>>>>>>>>>>>>> report that D(D) halts.

    This solution does seem to work correctly on >>>>>>>>>>>>>>>>>>>>>>>>>>> every conventional proof in >>>>>>>>>>>>>>>>>>>>>>>>>>> every textbook.


    So, did you make your "conventional proof" >>>>>>>>>>>>>>>>>>>>>>>>>> template actually use a copy of your ACTUAL >>>>>>>>>>>>>>>>>>>>>>>>>> decider (which seems to be your "batch file" >>>>>>>>>>>>>>>>>>>>>>>>>> not the C funciton H), or are you just >>>>>>>>>>>>>>>>>>>>>>>>>> admitting that you wasted 120 hours looking at >>>>>>>>>>>>>>>>>>>>>>>>>> the wrong thing because you have made yourself >>>>>>>>>>>>>>>>>>>>>>>>>> intentionally ignorant of the subject so you >>>>>>>>>>>>>>>>>>>>>>>>>> don't understand what you are trying to do. >>>>>>>>>>>>>>>>>>>>>>>>>
    New_D copies its input and simulates its input >>>>>>>>>>>>>>>>>>>>>>>>> with its input.
    It never sees New_H.


    Why not? Since New_H is the thing that is >>>>>>>>>>>>>>>>>>>>>>>> considered the "Correct Halt Decider", New_D >>>>>>>>>>>>>>>>>>>>>>>> needs to be built on it.


    New_H is embedded within New_D (as its middle >>>>>>>>>>>>>>>>>>>>>>> states) just the
    way it is supposed to be. The question is: Does >>>>>>>>>>>>>>>>>>>>>>> New_H(New_H) halt?

    The only difference at the source code level is: >>>>>>>>>>>>>>>>>>>>>>> (a) New_H copies its input, thus takes one param. >>>>>>>>>>>>>>>>>>>>>>> (b) New_H has an infinite loop at its accept state. >>>>>>>>>>>>>>>>>>>>>>
    So, how is New_H a halt decider then? >>>>>>>>>>>>>>>>>>>>>
    typo
    The only difference at the source code level is: >>>>>>>>>>>>>>>>>>>>> (a) New_D copies its input, thus takes one param. >>>>>>>>>>>>>>>>>>>>> (b) New_D has an infinite loop at its accept state. >>>>>>>>>>>>>>>>>>>>> Other than that (at the source-code level) New_D is >>>>>>>>>>>>>>>>>>>>> exactly New_H



    But New_D needs to call New_H,

    Not in the Peter Linz proof:
    https://www.liarparadox.org/Linz_Proof.pdf >>>>>>>>>>>>>>>>>>>
    In the Linz proof a copy of H is directly embedded >>>>>>>>>>>>>>>>>>> within Ĥ at this state: Ĥq0 Wm Wm
    The original H remains unchanged.

    The halting problem is about undecidable inputs, it >>>>>>>>>>>>>>>>>>> is not about
    inserting bugs into a halt decider to make it cease >>>>>>>>>>>>>>>>>>> to function.



    Right, and in Linz, H is the decider that is claimed >>>>>>>>>>>>>>>>>> to give the right answer.

    That isn't 'H' in your system, but the script that >>>>>>>>>>>>>>>>>> decides whether to use H or H1.

    Your error is in calling the wrong thing 'H' >>>>>>>>>>>>>>>>>>
    You are just showing you are lying by using the wrong >>>>>>>>>>>>>>>>>> name for things.

    You are using double-talk in a lame attempt to show that >>>>>>>>>>>>>>>>> Linz H cannot correctly determine the halt status of >>>>>>>>>>>>>>>>> Linz Ĥ.


    So you agree with the Theorem.

    No 'Linz H' can exist that correctly decides the halt >>>>>>>>>>>>>>>> status of Linz Ĥ applied to the description of Linz Ĥ. >>>>>>>>>>>>>>>>
    That is EXACTLY the consequence of the Halting Theorem. >>>>>>>>>>>>>>>>

    Please show an ACTUAL 'Linz H' that correctly gets the >>>>>>>>>>>>>>>> results of the 'Linz Ĥ' built on it. You keep on >>>>>>>>>>>>>>>> changing H and trying to use the old Ĥ which just fails >>>>>>>>>>>>>>>> to meet the requirement of the proof, likely because you >>>>>>>>>>>>>>>> just don't understand the theory involved.

    It took me two years to figure out a clean way to copy >>>>>>>>>>>>>>> the input to
    Linz_H_Hat and not have the system crash. Relative to >>>>>>>>>>>>>>> Linz_H_Hat
    Linz_H is H1. Now Linz_H_Hat only contradicts itself. >>>>>>>>>>>>>>>

    So, you are admitting that you actually can't do what is >>>>>>>>>>>>>> required?

    Copying the input should be trivial,

    The relative addressing of the x86 language causes all >>>>>>>>>>>>> function
    calls to call the wrong address.

    Only because you aren't interpreting the input properly, but >>>>>>>>>>>> in a non-Turing Complete manner.

    As I said, the input description should be a chunck of code >>>>>>>>>>>> in a virtual address space with a header that tells where >>>>>>>>>>>> that code is supposed to be considered to be located at. >>>>>>>>>>>>

    as the input should be a representation that packages a >>>>>>>>>>>>>> full program in its own virtual environment, so a simple >>>>>>>>>>>>>> bit by bit copy to empty ram will work. Your problem is >>>>>>>>>>>>>> that you don't put the input into its own virtual address >>>>>>>>>>>>>> space, so you have pathological interactions.

    Linz_H_Hat must be built on the exact code base that is >>>>>>>>>>>>>> deciding on it, in this case H, since you just said it >>>>>>>>>>>>>> isn't, your proof is invalid.


    Linz_Hat <is> Linz_H that takes one param  and copies it >>>>>>>>>>>>> instead of
    two params and has an infinite loop at its accept state. >>>>>>>>>>>>
    So, Two things that are different are exactly the same? >>>>>>>>>>>>

    It exactly matches the Linz spec.

    You don't seem to understand what you are doing.

    Linz_H_Hat (not Linz_Hat) is a Turing Machine with a defined >>>>>>>>>>>> behavior. That behavior is a function of its input, but >>>>>>>>>>>> hasn't been assigned any "meaning".

    Linz_H is a Turing Machine (if it actually can exist) that >>>>>>>>>>>> has a defined meaning/requirement for its final states. >>>>>>>>>>>> Linz_H, to meet its requirements, MUST go to Qy if the input >>>>>>>>>>>> represents a Halting Computation, and MUST go to Qn if the >>>>>>>>>>>> input represents a non-halting computation.

    Since Linz_H has actual requirements, a claimed
    implementation of it can be checked to see if it actually >>>>>>>>>>>> meets the requirements, and perhaps we can determine if it >>>>>>>>>>>> is possible to meet them.


    Note, Linz_H_Hat CAN'T "Contradict" itself, as doesn't >>>>>>>>>>>>>> generate any truth values, only behavior. You are just >>>>>>>>>>>>>> showing that you don't understand the basics of the >>>>>>>>>>>>>> requirements, and seem to think that "close" is good >>>>>>>>>>>>>> enough for proofs.

    Linz_H_Hat(Linz_H_Hat) returns 0.

    Actually no. Linz_H_Hat(Linz_H_Hat) halts at state Qn, >>>>>>>>>>>> which has NO
    defined meaning for Linz_H_Hat as it isn't defined to be a >>>>>>>>>>>> decider.

    Linz_H and Linz_H_Hat are C functions.
    Linz:H and Linz:Ĥ are Turing machines.

    So, inventing new terminology without introduction, thus
    showing you are being intentionally deceptive.


    Linz_H and Linz:H are both directly embedded within a copy of >>>>>>>>>>> Linz_H_Hat and Linz:Ĥ thus a return value of 0 or a transition >>>>>>>>>>> to Ĥ.qn still means not halting.

    No, because Linz_H_Hat / Linz:Ĥ are not "Halt Deciders" so >>>>>>>>>> there return value has no meaning.

    Ĥ has no meaning, so it can't be "incorrect" or contradicted. >>>>>>>>>>

    This allows Linz_H and Linz:H correctly report on the actual >>>>>>>>>>> behavior of their input.



    No, since BOTH have an input that when run will HALT, and both >>>>>>>>>> report that it will not, both are just wrong.

    Linz_H(Linz_H_Hat, Linz_H_Hat) is claimed to "correctly"
    return 0,
    *I never said that you are confused*

    You always claim that your H by its various names is "Correct" >>>>>>>> to return 0 as the input is non-halting because its "correct
    simulation" will never reach a final state.

    I think your brain is turning into mush, or is your pathology
    overloading and trying to reverse the argument.

    Linz_H_Hat(Linz_H_Hat) returns 0 permitting
    Linz_H(Linz_H_Hat, Linz_H_Hat) to correctly return 1.


    But if Linz_H(Linz_H_Hat, Linz_H_Hat) returns 1, which means
    Halting,

    Linz_H_Hat has its own embedded_H that returns 0.
    Linz_H_Hat has no access to Linz_H, only to its own embedded copy. >>>>>>
    But embedded_H is an identical copy to Linz_H, so if embedded_H
    returns 0, so does Lin

    Linz_H simply simulates Linz_H_Hat until it terminates.

    Then so must embedded_H, since it is an identical copy, and as you >>>>>> have shown before, if H is defined that way, the H_Hat will never
    halt, and thus H, since for this case you said it doesn't abort,
    will also never halt and fail to be a decider.


    We have gone through this many hundreds of times.
    It is the exact same H(D,D) versus H1(D,D) thing.

    Linz_H_Hat now has a pathological relationship to itself
    this frees Linz_H from such a pathological relationship.
    So Linz_H becomes H1, and Linz_H_Hat becomes H.

    Nope, just shows you are not working in a Turing Equivalent system,
    and thus NOTHING you say matters.


    You can make such claims with bluster finding a source that actually
    supports them is a whole different matter.

    No, you are just showing that you believe Russell's Teapot actually
    exists. YOU are the one making claims, so YOU are the one that needs
    to make a actual proof of correctness, and show the error in the
    counter claims.


    If you believe that I am incorrect you need much more than your own presumption as a basis for an actual rebuttal. You might not have
    much more than this mere presumption.

    I have given MANY details that you have not even tried to refute.

    YOU are the one with the burden of Proof.

    The Ultimate proof you are wrong is that H, which you claim to be a
    correct Halt decider, will return 0 when called as H(D,D), but D(D)
    Halts, as you admit, which is contrary to the requirements of a Halt
    Decider.

    Thus, you claim is just a LIE.


    It is a PROVEN fact that two computation machines with the exact same
    algorithm and the exact same input will always produce the same result.

    You are claiming differently, WITHOUT PROOF, so you are shown to be a
    LIAR.


    H1(D,D) and H(D,D) have different execution traces because D calls H and
    D does not call H1. A not very bright software engineer could understand this.

    Then they aren't the same algorithm, and can't be considered the same
    machine.

    PERIOD.

    You are caught in your lie.

    When you try to show where the traces differ, it shows that the machines
    are NOT exact copies of the same algorthm that uses only its defined
    inputs to control itself.

    Therefore, H1 is a DIFFERENT machine the H, so it giving the correct
    answer is irrelevent, and you claims are shown to be a LIE.


    Either H and H1 are claimed to be the same machine, or they are not.
    If they are the same machine, they need to give the same answer, or
    they are not, and thus H1 getting the right answer to the H^ built on
    H doesn't matter.


    It is the case that when embedded_H is a simulating termination analyzer >>> applied to ⟨Ĥ⟩ ⟨Ĥ⟩ that the simulated input cannot possibly terminate
    normally and must have its simulation aborted.

    So?


    It is not the case the Linz:H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ that its input must
    have its simulation terminated.

    Thus Linz:H and embedded_H aren't the same machine, as REQUIRED, thus
    showing that you hav just been LYING for decades.

    It is a simple execution trace that even a bright high school student
    can understand now that I have shown it at the C source code level.

    Which shows that your claims are a lie, as shown above.




    Now, since you are claiming that the embedded_H and Linz_H are
    IDENTICAL machines, but the also produce DIFFERENT results when
    given identical inputs, you have just proven that you are a LIAR.

    *So you are back to rejecting verified facts out-of-hand*
    It is a verified fact that H(D,D) returns 0 and H1(D,D) returns
    1 and the only difference is that H1 does not have a pathological
    relationship to H and it is otherwise identical to H.


    Since youy refuse to provide the verification fact about where the
    paths of H(D,D) and D(D) differ, you don't HAVE a "verified fact".


    The source code and execution trace have been available for a year.
    I have explained this many times the problem seems to be that you simply >>> don't believe the facts. You say that a simulation is incorrect yet
    cannot point to the instruction that was simulated incorrectly only
    because the simulation is actually correct.

    No, YOU LIE. The "Call H" instruction has been simulated incorrectly
    (or not simulated at all an false presumptions about what it does used).


    You are just proving that you are just a LIAR and an IDIOT.

    What IS verified is that D(D) Halts, so H(D,D) returning 0 is BY
    DEFINITION WRONG and you claim tha tit is right is a verified LIE.


    It depends on how you frame the problem.
    If you frame the problem in that a halt decider must divide up finite
    strings pairs into those that halt when directly executed and those that >>> do not, then no single program can do this. A pair of programs might do
    this.

    So, you agree with the Halting Theorem, as that it is the precise
    problem being asked about.


    If you frame the problem in that a halt decider must divide up finite
    stings into those that must have their simulation aborted to prevent
    their infinite execution, then from H's point of view D does not halt.


    So, you are admitting to using a Strawman, and nothing you say applies
    to the ACTUAL Halting Problem.

    You have maybe shown that POOP might be decidable, it at least can't
    use the simple pathological example to show it, but POOP isn't about
    Halting but partial simulation, so who cares about it.

    This shows your mental instability as we don't care about what H sees,
    which is just something of its imagination, we care about the reality
    of what D actually does. Just like we care about what is ACTUALLY
    true, verses what you think must be true without actually trying to
    prove it logically.

    It turns out that Linz_H(Linz_H_Hat, Linz_H_Hat) == 1
    because Linz_H_Hat(Linz_H_Hat) == 0

    ?? Linz_H isn't defined to "call" Linz_H_Hat, in fact it CAN'T because Linz_H_Hat doesn't exist when Linz_H is defined. it might "Simulate" or
    "Debug Step" the description it gets. Also Linz_H_Hat doesn't actually
    returh anything of meaning, as has been previously told to you.

    Also, if Linz_H(Linz_H_Hat, Linz_H_Hat) returns 1, then so must the embedded_H(Linz_H_Hat, Linz_H_Hat) that Linz_H_Hat uses, or it is proven
    that you claim that you built Linz_H_Hat per the requirements is a LIE.

    Linz_H_Hat is DEFINED to use a computationally equivalent copy of Linz_H
    within it, and as such that copy must return the same value for the same inputs. That you embedded_H doesn't just proves you failed to perform
    this step correctly.

    And you traces just confirm this fact, there will either be a differing
    effect instruction/data in embedded_H or it uses a value not part of its
    input (like its PC address), thus invalidating your claims.

    Remember, you are claiming Turing Equivalence to the Turing Machine description, so you need to be an ACTUAL equivalent, and


    This translates into Linz:H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly transitions to Linz:H.qy because Linz:Ĥ applied to ⟨Ĥ⟩
    transitions to Linz:Ĥ.qn

    But Linz:Ĥ uses its copy of embedded_H (Ĥ) (Ĥ) which will behave
    IDENTIALLY to Linz:H (Ĥ) (Ĥ) which by your claim above goes to Qy, so
    Linz:Ĥ will go to Qy and then on to the infinite loop, so Linz:H going
    to Qy is incorrect.


    So I have overcome the issue of H(D,D) reporting non-halting and
    the directly executed D(D) then halting in two different ways:

    (1) Linz_H(Linz_H_Hat, Linz_H_Hat) reports halting and
    Linz_H_Hat(Linz_H_Hat) halts.

    But only because you didn't build Ĥ correctly, and thus you are caught
    in your LIE.


    (2) With the three value return of H(D,D) H only reports halting
    when its directly executed input actually halts and seems to
    defeat Rice by separately reporting all conventional halting
    problem proof pathological inputs.



    Nope. You have just shown that you whole proof is built on LIES and your
    own ignorance.

    The claims you make just prove you don't understand the words you are
    sayimg.

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