• H1(P,P) is a halt decider for P(P) [ meeting the infinite recursion

    From olcott@21:1/5 to All on Wed Sep 8 17:00:31 2021
    XPost: comp.theory, sci.logic, sci.math

    On 9/8/2021 4:27 PM, André G. Isaak wrote:
    On 2021-09-08 14:41, olcott wrote:
    On 9/8/2021 3:02 PM, André G. Isaak wrote:
    On 2021-09-08 13:33, olcott wrote:
    On 9/8/2021 2:13 PM, olcott wrote:
    On 9/8/2021 1:58 PM, André G. Isaak wrote:
    On 2021-09-08 12:12, olcott wrote:
    On 9/8/2021 12:59 PM, André G. Isaak wrote:

    But ⟨Ĥ⟩ ⟨Ĥ⟩ represents a *single* computation. It either halts
    or it doesn't.


    We could say the same thing about P(P), yet we can clearly see every >>>>>>
    Yes, we could and I did.

    single step where H1(P,P) correctly reports that its input halts >>>>>>> because H(P,P) correctly reports that its input never halts.

    H(P, P) *can't* correctly report that its input never halts
    because P(P) does halt.

    You can ignore this forever, yet that will not make a verifiable >>>>>>> fact simply go away.

    You're ignoring the fact that it gets the answer wrong since you
    are overlooking the actual definition of the halting problem.

    We can see that unless H(P,P) aborts the simulation of its input
    that its input never halts.

    You've said this many times but it is simply wrong. We know that P(P)
    is a halting computation.

    You can say that you don't see this only because you don't look at it. >>>>> At this point after it has been brought up so many times you must
    simply be a God damned liar.




    Begin Local Halt Decider Simulation at Machine Address:c36
    [00000c36][002117ca][002117ce] 55          push ebp
    [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
    [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
    [00000c3c][002117c6][00000c36] 50          push eax       // push P
    [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
    [00000c40][002117c2][00000c36] 51          push ecx       // push P
    [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call
    H(P,P)

    [00000c36][0025c1f2][0025c1f6] 55          push ebp
    [00000c37][0025c1f2][0025c1f6] 8bec        mov ebp,esp
    [00000c39][0025c1f2][0025c1f6] 8b4508      mov eax,[ebp+08]
    [00000c3c][0025c1ee][00000c36] 50          push eax       // push P
    [00000c3d][0025c1ee][00000c36] 8b4d08      mov ecx,[ebp+08]
    [00000c40][0025c1ea][00000c36] 51          push ecx       // push P
    [00000c41][0025c1e6][00000c46] e820fdffff  call 00000966  // call
    H(P,P)
    Local Halt Decider: Infinite Recursion Detected Simulation Stopped

    The above code does match this infinite recursion pattern and the
    infinite recursion pattern is correct therefore the input to H(P,P)
    never halts even if an omniscient being disagrees.

    A trace shows *how* a particular program got to a particular answer.
    It in no way establishes that that answer is actually correct. Traces
    are not proofs. If you ever attempt to publish your work, no one is
    even going to be willing to look at a trace.

    The problem is that your 'infinite recursion pattern' doesn't work.

    And how can something be 'correct' if an omniscient being (taking the
    term literally) disagrees?

    This infinite recursion detection criteria are met by the above
    execution trace:
    (a) P calls H twice in sequence from the same machine address.
    (b) With the same parameters: (P,P) to H.
    (c) With no conditional branch or indexed jump instructions in the
    execution trace of P.
    (d) We know that there are no return instructions in H because we
    know that H is in pure simulation mode.

    As has been pointed out many times, your (d) is simply wrong. It
    cannot be justified in any way. And your (d) is why your H
    erroneously concludes that P(P) halts.

    But even if we ignore (d), you can't just pull some criteria out of
    your ass and claim that these criteria work without providing actual
    proof. I can think of numerous ways to construct a C routine which
    would meet conditions (a)-(c) but which would not be infinitely
    recursive.


    If X has no effect on Y until after Z then X can be ignored before Z.
    X is a simulating halt decider
    Y is its input program
    Z When X makes its halt status decision.

    THIS IS A TRUISM THUS DISAGREEMENT IS ERROR
    While H acts as a pure simulator of P(P) nothing that X does has any
    effect on the behavior of P(P) therefore X can ignore its own behavior
    while making its halt status decision.

    Declaring something to be a 'truism' doesn't magically make it true.
    That requires actual proof which you haven't given, whereas many people (myself included) have already explained at length why it is wrong.


    It is impossibly incorrect.
    Maybe this simplification is easy enough for you to understand:

    If X cannot possibly have any effect on Y then there is never any reason
    to study the effect of X on Y.

    It might sound plausible, but your sloppy use of the term 'its' destroys
    that plausibilty.

    The only way to prove that the above infinite recursion detection
    criteria are correct is to show that there are no counter-examples of
    cases that meet the criteria and are not infinitely recursive.

    Once (a)(b)(c)(d) criteria have been met
    not infinitely recursive is categorically impossible.

    As I said, I can think of numerous ways to write a C program which meets those requirements but which is not infinitely recursive.

    Name at least one. That list has been the subject of numerous revisions
    to make it as simple as possible.

    So clearly it
    isn't "categorically impossible". You should think about this rather
    harder. If you can't come up with counterexamples in a week or so maybe
    I'll provide some.

    It has already been reviewed by two dozen reviewers, some of them
    thought the same thing until they realized that they did not actually
    pay attention to all the criteria.


    The crucial point is that just because *you* haven't thought of counterexamples doesn't mean there aren't any.

    The only proof that it is true is a proof that no counter-examples can
    possibly exist.

    You can't just declare
    something to be 'categorically impossible' unless you can actually
    *prove* this. You have note.

    And of course, even if these criteria worked they are completely
    worthless where actually TMs are concerned since TMs don't have machine addresses and can't call things.

    This has been somewhat extensively reviewed.

    Which, again, doesn't make it true. It's not incumbent on others to make
    your case for you, and you make so many errors that people can't be
    bothered to point out all of them. People have been more focused on your patently false (d) rather than on the other three since that's the one
    which causes your H to get the wrong answer.

    André


    The criteria for the actual Linz Ĥ are simply a little more difficult.



    --
    Copyright 2021 Pete Olcott

    "Great spirits have always encountered violent opposition from mediocre
    minds." Einstein

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to All on Wed Sep 8 17:34:25 2021
    XPost: comp.theory, sci.logic, sci.math

    On 9/8/2021 5:20 PM, André G. Isaak wrote:
    On 2021-09-08 16:00, olcott wrote:
    On 9/8/2021 4:27 PM, André G. Isaak wrote:
    On 2021-09-08 14:41, olcott wrote:

    Declaring something to be a 'truism' doesn't magically make it true.
    That requires actual proof which you haven't given, whereas many
    people (myself included) have already explained at length why it is
    wrong.


    It is impossibly incorrect.

    "impossibly incorrect" is not English. Illiterate buffoon makes you look
    like your continual (mis)use of this term.

    Maybe this simplification is easy enough for you to understand:

    If X cannot possibly have any effect on Y then there is never any
    reason to study the effect of X on Y.

    When H(P, P) is called, H cannot have an effect on P(P), but P(P) makes
    its own call to H(P, P). Your upper H *cannot* ignore this one because
    it is an entirely different process. It is *part* of the P(P) being
    evaluated by the upper H.

    This is patently obvious to everyone but you.

    So go one and show the actual "patently obvious" error.
    I am calling your bluff!

    I know that no H in the entire recursive invocation chain has any effect
    on the behavior of its input until after the outer-most H makes its halt
    status decision.

    I know that this outer-most H makes its halt status decision on the
    basis that the behavior of its input has matched the infinite recursion behavior pattern.


    Calling something a 'truism' when you haven't been able to convince even
    a single person of its truth is hardly warranted.

    It might sound plausible, but your sloppy use of the term 'its'
    destroys that plausibilty.

    The only way to prove that the above infinite recursion detection
    criteria are correct is to show that there are no counter-examples
    of cases that meet the criteria and are not infinitely recursive.

    Once (a)(b)(c)(d) criteria have been met
    not infinitely recursive is categorically impossible.

    As I said, I can think of numerous ways to write a C program which
    meets those requirements but which is not infinitely recursive.

    Name at least one. That list has been the subject of numerous
    revisions to make it as simple as possible.

    I told you that I would, but that I would first give you a week or so to think about it further. Your approach has always been "this works for
    all the cases I considered, therefore it works in all cases" which is
    *not* valid logic. You should perhaps think of more cases. But of course
    it doesn't matter how many cases you consider, there will always be
    cases you haven't considered. That's why a proof can't simply consist of showing it works in some cases.


    This has been under review for many months.
    I am calling your bluff.


    --
    Copyright 2021 Pete Olcott

    "Great spirits have always encountered violent opposition from mediocre
    minds." Einstein

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to All on Thu Sep 9 08:34:31 2021
    XPost: comp.theory, sci.logic, sci.math

    On 9/9/2021 12:16 AM, André G. Isaak wrote:
    On 2021-09-08 20:02, olcott wrote:
    On 9/8/2021 8:21 PM, André G. Isaak wrote:
    On 2021-09-08 16:34, olcott wrote:
    On 9/8/2021 5:20 PM, André G. Isaak wrote:
    On 2021-09-08 16:00, olcott wrote:
    On 9/8/2021 4:27 PM, André G. Isaak wrote:
    On 2021-09-08 14:41, olcott wrote:

    Declaring something to be a 'truism' doesn't magically make it
    true. That requires actual proof which you haven't given, whereas >>>>>>> many people (myself included) have already explained at length
    why it is wrong.


    It is impossibly incorrect.

    "impossibly incorrect" is not English. Illiterate buffoon makes you
    look like your continual (mis)use of this term.

    Maybe this simplification is easy enough for you to understand:

    If X cannot possibly have any effect on Y then there is never any
    reason to study the effect of X on Y.

    When H(P, P) is called, H cannot have an effect on P(P), but P(P)
    makes its own call to H(P, P). Your upper H *cannot* ignore this
    one because it is an entirely different process. It is *part* of
    the P(P) being evaluated by the upper H.

    This is patently obvious to everyone but you.

    So go one and show the actual "patently obvious" error.
    I am calling your bluff!

    I just did. The H which is *evaluating* the input P(P) can't affect
    the behaviour of its input, but the second call to H *isn't*
    evaluating P(P), it is *part* of the computation performed by P(P)
    and that computation is critically dependent on what that H does. You
    can't just ignore it.


    None of the recursive invocations of H has any effect on the behavior
    of its input until after the behavior of its input has matched the
    INFINITE_LOOP or INFINITE_RECURSION behavior pattern.

    Every time that such a rebuttal is made I utterly refute it and my
    refutation is simply ignored. Later on the same lame rebuttal (that
    does not even bother to connect most of its ideas together) is
    presented again.

    You've never 'utterly refuted' anything. You just keep reiterating your original position in response to clear evidence that your initial
    position is simply wrong.

    The key evidence is my code and you can't see my code so you can't
    truthfully say what my code does. Even though you can't truthfully say
    this you dishonestly say what it does anyway.

    You keep using terms like 'its input' and 'its
    simulator' where 'its' rather sloppily refers to the wrong things. You
    really need to strike the word 'its' from your vocabulary altogether.


    When H(P,P) is invoked none of its recursive invocations has any effect
    on the halting behavior of P(P) until after a non-halting behavior
    pattern has been matched.

    Until a non-halting behavior pattern has been matched H merely simulates
    its input and examines the execution trace of this simulation. Neither
    of these things can possibly have any effect on the behavior of the input.

    I know that no H in the entire recursive invocation chain has any
    effect on the behavior of its input until after the outer-most H
    makes its halt status decision.

    I know that this outer-most H makes its halt status decision on the
    basis that the behavior of its input has matched the infinite
    recursion behavior pattern.

    But your 'infinite recursion behaviour pattern' is flawed. In this
    particular instance precisely because of your (d).


    Calling something a 'truism' when you haven't been able to convince
    even a single person of its truth is hardly warranted.

    It might sound plausible, but your sloppy use of the term 'its'
    destroys that plausibilty.

    The only way to prove that the above infinite recursion
    detection criteria are correct is to show that there are no
    counter-examples of cases that meet the criteria and are not
    infinitely recursive.

    Once (a)(b)(c)(d) criteria have been met
    not infinitely recursive is categorically impossible.

    As I said, I can think of numerous ways to write a C program
    which meets those requirements but which is not infinitely
    recursive.

    Name at least one. That list has been the subject of numerous
    revisions to make it as simple as possible.

    I told you that I would, but that I would first give you a week or
    so to think about it further. Your approach has always been "this
    works for all the cases I considered, therefore it works in all
    cases" which is *not* valid logic. You should perhaps think of more
    cases. But of course it doesn't matter how many cases you consider,
    there will always be cases you haven't considered. That's why a
    proof can't simply consist of showing it works in some cases.


    This has been under review for many months.
    I am calling your bluff.

    Your really that adverse to thinking on something for a week?

    Just to give you a few hints, though, your (a)-(c) make no mention of
    (among other things) cases where the routine manipulates the contents
    of the stack or the stack pointer, or cases where the routine
    involves self-modifying code. There's all sorts of creative ways to
    meet your criteria without being infinitely recursive using those.


    I am not convinced that this is a counter-example, yet it does seem
    reasonably plausible. The current code does not do that so we can see
    that the halt decider did decide correctly.

    Whether you are convinced or not isn't the issue. Since you claim it is 'reasonably plausible' you need to actually think it through. I assure
    you it is possible to create routines which meet your 'infinite
    recursion pattern' but which are not infinitely recursive using these strategies. Without actually showing that it is *impossible* to do so
    (which you can't because it isn't), claiming you don't find it
    convincing doesn't get you very far.

    Whether the current code does so or not isn't relevant since I was
    responding to your statement that once your criteria are met "not
    infinitely recursive is categorically impossible."


    I concede that you may be right.

    This only requires that the halt decider be made more elaborate, not
    that the "impossible input" cannot be correctly decided.

    'Must be made more elaborate' isn't worth much unless you can actually demonstrate that it is *possible* to make them more elaborate to the
    extent that they cover all cases. You can't.


    It need not cover all cases. It only needs to cover the simplest
    instance of the "impossible" case. It does that now. Human inspection of
    the code (by honest people that know the x86 language) proves that it
    never halts unless H aborts its simulation of this code.

    I simply assume that all of the code is generated by the Microsoft C
    compiler. x86utm can only read COFF object files.

    Relevance? The strategies for breaking your 'infinite recursion pattern'
    I offered are all possible using the Microsoft C compiler.

    André




    --
    Copyright 2021 Pete Olcott

    "Great spirits have always encountered violent opposition from mediocre
    minds." Einstein

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?B?QW5kcsOpIEcuIElzYWFr?=@21:1/5 to olcott on Thu Sep 9 15:08:45 2021
    XPost: comp.theory, sci.logic, sci.math

    On 2021-09-09 07:34, olcott wrote:
    On 9/9/2021 12:16 AM, André G. Isaak wrote:
    On 2021-09-08 20:02, olcott wrote:
    On 9/8/2021 8:21 PM, André G. Isaak wrote:
    On 2021-09-08 16:34, olcott wrote:
    On 9/8/2021 5:20 PM, André G. Isaak wrote:
    On 2021-09-08 16:00, olcott wrote:
    On 9/8/2021 4:27 PM, André G. Isaak wrote:
    On 2021-09-08 14:41, olcott wrote:


    The key evidence is my code and you can't see my code so you can't
    truthfully say what my code does. Even though you can't truthfully say
    this you dishonestly say what it does anyway.

    I see. The "I have proof but its level 12 scientology and you're only
    paid up for level 9" defence.

    I'm sure that will go over well with actual journals. "The key evidence
    is my code but you're not allowed to see it."

    You keep using terms like 'its input' and 'its simulator' where 'its'
    rather sloppily refers to the wrong things. You really need to strike
    the word 'its' from your vocabulary altogether.


    When H(P,P) is invoked none of its recursive invocations has any effect
    on the halting behavior of P(P) until after a non-halting behavior
    pattern has been matched.

    Yet another 'its'.

    Until a non-halting behavior pattern has been matched H merely simulates
    its input and examines the execution trace of this simulation. Neither
    of these things can possibly have any effect on the behavior of the input.

    But your halting pattern doesn't actually work.

    I know that no H in the entire recursive invocation chain has any
    effect on the behavior of its input until after the outer-most H
    makes its halt status decision.

    I know that this outer-most H makes its halt status decision on the
    basis that the behavior of its input has matched the infinite
    recursion behavior pattern.

    But your 'infinite recursion behaviour pattern' is flawed. In this
    particular instance precisely because of your (d).


    Calling something a 'truism' when you haven't been able to
    convince even a single person of its truth is hardly warranted.

    It might sound plausible, but your sloppy use of the term 'its' >>>>>>>> destroys that plausibilty.

    The only way to prove that the above infinite recursion
    detection criteria are correct is to show that there are no
    counter-examples of cases that meet the criteria and are not >>>>>>>>> infinitely recursive.

    Once (a)(b)(c)(d) criteria have been met
    not infinitely recursive is categorically impossible.

    As I said, I can think of numerous ways to write a C program
    which meets those requirements but which is not infinitely
    recursive.

    Name at least one. That list has been the subject of numerous
    revisions to make it as simple as possible.

    I told you that I would, but that I would first give you a week or >>>>>> so to think about it further. Your approach has always been "this
    works for all the cases I considered, therefore it works in all
    cases" which is *not* valid logic. You should perhaps think of
    more cases. But of course it doesn't matter how many cases you
    consider, there will always be cases you haven't considered.
    That's why a proof can't simply consist of showing it works in
    some cases.


    This has been under review for many months.
    I am calling your bluff.

    Your really that adverse to thinking on something for a week?

    Just to give you a few hints, though, your (a)-(c) make no mention
    of (among other things) cases where the routine manipulates the
    contents of the stack or the stack pointer, or cases where the
    routine involves self-modifying code. There's all sorts of creative
    ways to meet your criteria without being infinitely recursive using
    those.


    I am not convinced that this is a counter-example, yet it does seem
    reasonably plausible. The current code does not do that so we can see
    that the halt decider did decide correctly.

    Whether you are convinced or not isn't the issue. Since you claim it
    is 'reasonably plausible' you need to actually think it through. I
    assure you it is possible to create routines which meet your 'infinite
    recursion pattern' but which are not infinitely recursive using these
    strategies. Without actually showing that it is *impossible* to do so
    (which you can't because it isn't), claiming you don't find it
    convincing doesn't get you very far.

    Whether the current code does so or not isn't relevant since I was
    responding to your statement that once your criteria are met "not
    infinitely recursive is categorically impossible."


    I concede that you may be right.

    Which is an acknowledgment that your criteria are not sound.

    This only requires that the halt decider be made more elaborate, not
    that the "impossible input" cannot be correctly decided.

    'Must be made more elaborate' isn't worth much unless you can actually
    demonstrate that it is *possible* to make them more elaborate to the
    extent that they cover all cases. You can't.


    It need not cover all cases. It only needs to cover the simplest
    instance of the "impossible" case. It does that now. Human inspection of
    the code (by honest people that know the x86 language) proves that it
    never halts unless H aborts its simulation of this code.

    But your 'argument' for H(P, P)==0 being 'correct' rests on the claim
    that your criteria are sound. They are not. It also rests on the
    assumption that the actual answer isn't important which is a rather odd position to take.

    To get the "impossible" case right, you need H(P, P)==1.

    André

    --
    To email remove 'invalid' & replace 'gm' with well known Google mail
    service.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to All on Thu Sep 9 17:15:32 2021
    XPost: comp.theory, sci.logic, sci.math

    On 9/9/2021 4:08 PM, André G. Isaak wrote:
    On 2021-09-09 07:34, olcott wrote:
    On 9/9/2021 12:16 AM, André G. Isaak wrote:
    On 2021-09-08 20:02, olcott wrote:
    On 9/8/2021 8:21 PM, André G. Isaak wrote:
    On 2021-09-08 16:34, olcott wrote:
    On 9/8/2021 5:20 PM, André G. Isaak wrote:
    On 2021-09-08 16:00, olcott wrote:
    On 9/8/2021 4:27 PM, André G. Isaak wrote:
    On 2021-09-08 14:41, olcott wrote:


    The key evidence is my code and you can't see my code so you can't
    truthfully say what my code does. Even though you can't truthfully say
    this you dishonestly say what it does anyway.

    I see. The "I have proof but its level 12 scientology and you're only
    paid up for level 9" defence.

    I'm sure that will go over well with actual journals. "The key evidence
    is my code but you're not allowed to see it."

    You keep using terms like 'its input' and 'its simulator' where 'its'
    rather sloppily refers to the wrong things. You really need to strike
    the word 'its' from your vocabulary altogether.


    When H(P,P) is invoked none of its recursive invocations has any
    effect on the halting behavior of P(P) until after a non-halting
    behavior pattern has been matched.

    Yet another 'its'.

    Should I have used thems instead?


    Until a non-halting behavior pattern has been matched H merely
    simulates its input and examines the execution trace of this
    simulation. Neither of these things can possibly have any effect on
    the behavior of the input.

    But your halting pattern doesn't actually work.


    It is quite dishonest to say that something that works quite well for
    its intended purpose does not work at all.


    I know that no H in the entire recursive invocation chain has any
    effect on the behavior of its input until after the outer-most H
    makes its halt status decision.

    I know that this outer-most H makes its halt status decision on
    the basis that the behavior of its input has matched the infinite
    recursion behavior pattern.

    But your 'infinite recursion behaviour pattern' is flawed. In this
    particular instance precisely because of your (d).


    Calling something a 'truism' when you haven't been able to
    convince even a single person of its truth is hardly warranted.

    It might sound plausible, but your sloppy use of the term 'its' >>>>>>>>> destroys that plausibilty.

    The only way to prove that the above infinite recursion
    detection criteria are correct is to show that there are no >>>>>>>>>> counter-examples of cases that meet the criteria and are not >>>>>>>>>> infinitely recursive.

    Once (a)(b)(c)(d) criteria have been met
    not infinitely recursive is categorically impossible.

    As I said, I can think of numerous ways to write a C program >>>>>>>>> which meets those requirements but which is not infinitely
    recursive.

    Name at least one. That list has been the subject of numerous
    revisions to make it as simple as possible.

    I told you that I would, but that I would first give you a week
    or so to think about it further. Your approach has always been
    "this works for all the cases I considered, therefore it works in >>>>>>> all cases" which is *not* valid logic. You should perhaps think
    of more cases. But of course it doesn't matter how many cases you >>>>>>> consider, there will always be cases you haven't considered.
    That's why a proof can't simply consist of showing it works in
    some cases.


    This has been under review for many months.
    I am calling your bluff.

    Your really that adverse to thinking on something for a week?

    Just to give you a few hints, though, your (a)-(c) make no mention
    of (among other things) cases where the routine manipulates the
    contents of the stack or the stack pointer, or cases where the
    routine involves self-modifying code. There's all sorts of creative
    ways to meet your criteria without being infinitely recursive using
    those.


    I am not convinced that this is a counter-example, yet it does seem
    reasonably plausible. The current code does not do that so we can
    see that the halt decider did decide correctly.

    Whether you are convinced or not isn't the issue. Since you claim it
    is 'reasonably plausible' you need to actually think it through. I
    assure you it is possible to create routines which meet your
    'infinite recursion pattern' but which are not infinitely recursive
    using these strategies. Without actually showing that it is
    *impossible* to do so (which you can't because it isn't), claiming
    you don't find it convincing doesn't get you very far.

    Whether the current code does so or not isn't relevant since I was
    responding to your statement that once your criteria are met "not
    infinitely recursive is categorically impossible."


    I concede that you may be right.

    Which is an acknowledgment that your criteria are not sound.

    You know this is not the case and it is a damn lie for you to say
    otherwise. Unsound means always wrong.


    This only requires that the halt decider be made more elaborate, not
    that the "impossible input" cannot be correctly decided.

    'Must be made more elaborate' isn't worth much unless you can
    actually demonstrate that it is *possible* to make them more
    elaborate to the extent that they cover all cases. You can't.


    It need not cover all cases. It only needs to cover the simplest
    instance of the "impossible" case. It does that now. Human inspection
    of the code (by honest people that know the x86 language) proves that
    it never halts unless H aborts its simulation of this code.

    But your 'argument' for H(P, P)==0 being 'correct' rests on the claim
    that your criteria are sound. They are not. It also rests on the
    assumption that the actual answer isn't important which is a rather odd position to take.


    By human inpection we can that the exception to the rule is not met thus
    the criteria did work correctly for its input. It really is quite
    dishonest of you to say otherwise. Why lie?

    To get the "impossible" case right, you need H(P, P)==1.

    André



    --
    Copyright 2021 Pete Olcott

    "Great spirits have always encountered violent opposition from mediocre
    minds." Einstein

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Richard Damon on Sat Sep 11 22:53:00 2021
    XPost: comp.theory, sci.logic, sci.math

    On 9/11/2021 6:41 PM, Richard Damon wrote:
    On 9/11/21 7:14 PM, olcott wrote:
    On 9/11/2021 6:05 PM, Richard Damon wrote:
    On 9/11/21 6:53 PM, olcott wrote:

    It is a verifiable fact that none of them do until after the halt status >>>> decision is made thus eliminating the otherwise impossible feedback loop >>>> where the input changes its behavior based on the behavior of the halt >>>> decider.


    If tempreral order of decision and action matter, decide that you will
    live, then put a pistol to your head and pull the trigger. Since you did >>> that action after deciding otherwise it won't have any affect, right?

    That is your claim.

    The fact that H will at some point make the decision to abort its
    simulation and return non-halting, means that it does affect that
    machine that it is calling it, and that machine will halt.


    That topic is not under discussion.

    Why not?

    We are only discussing whether or not H can ignore its own behavior when
    it examines the execution trace of its input.

    Since H DOES abort it simulation and return the non-halting answer to P
    and that causes P to halt shows that the H simulating this machihne
    can't ignore that behavior.

    I say H does not have any effect on the simulation of its input while H
    remains in pure simulation mode.

    Your fake "rebuttal" claims that I am wrong because H does have an
    effect on its input when H is not in pure simulation mode.

    Even fools can tell that is a dishonest move, and there are no fools in
    this forum. Why foolishly lie?

    A straw man (sometimes written as strawman) is a form of argument and an informal fallacy of having the impression of refuting an argument,
    whereas the real subject of the argument was not addressed or refuted,
    but instead replaced with a false one.
    https://en.wikipedia.org/wiki/Straw_man


    --
    Copyright 2021 Pete Olcott

    "Great spirits have always encountered violent opposition from mediocre
    minds." Einstein

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olcott@21:1/5 to Richard Damon on Sun Sep 12 13:44:11 2021
    XPost: comp.theory, sci.logic, sci.math

    On 9/12/2021 1:35 PM, Richard Damon wrote:
    On 9/12/21 2:00 PM, olcott wrote:
    On 9/12/2021 12:51 PM, André G. Isaak wrote:
    On 2021-09-12 11:31, olcott wrote:
    On 9/12/2021 12:20 PM, André G. Isaak wrote:
    On 2021-09-12 11:00, olcott wrote:
    On 9/12/2021 10:47 AM, André G. Isaak wrote:
    On 2021-09-12 07:43, olcott wrote:

    [I say that H does not have any effect on the behavior of its
    input while H remains in pure simulation mode]

    Do you agree with the above statement: Yes or No.

    Your language is so equivocal that I can't make out whether you >>>>>>>> agree with the above statement or not. We can move on to the next >>>>>>>> half of the same point if you agree with the above statement.

    There's nothing remotely equivocal about Richard's language.


    The boil it down to a Yes or No:

    [I say that H does not have any effect on the behavior of its input >>>>>> while H remains in pure simulation mode]

    Do you agree with the above statement: Yes or No.

    Any reply besides Yes or No will be construed as a dishonest dodge. >>>>>
    You can't demand a yes or no answer if the statement itself is
    ambiguous or poorly defined.

    Your statement can be construed as true for certain interpretations
    of that statement (one in which the terms used have *consistent*
    referents), but it is clear that you are *not* using that
    interpretation but another interpretation which is clearly false.


    OK then I will define pure simulation mode tautologically.
    The simulation mode of a simulating halt decider is defined as the
    mode such that the simulating halt decider only acts as a pure
    simulator of its input that watches the execution trace of this input
    and has no effect on the behavior of its input while it is in
    simulation mode.

    And how does that fix anything? You're still abusing the referents in
    the above. (And btw you really need to come up with a better term than
    'mode'. Computations don't have "modes.")

    Let's try to lay this out more clearly. You have a halt decider, A,
    which takes an input, B. In this example the halt decider A is H and
    the input B is P(P). While B is being simulated, it simulates another
    computation C with an input D. Once again in this case C equals H and
    D equals P(P).


    No. Simulating halt decider H which simulates its input P
    calls simulating halt decider H which simulates its input P
    calls simulating halt decider H which simulates its input P

    The key fact that you seem to miss is that each of those things called 'simulating halt decider H' are distinct instances of the execution of
    the algorithm of your Halt Decider, and properties that actually refer
    to a given instance, apply only to the one that the property applies to.
    SUMMATION

    The bottom line of all of this is that all of the conventional halting
    problem counter examples can be recognized as infinitely recursive
    simulation to every simulating halt decider.

    This simulating halt decider must remain in pure simulation mode until
    after it detects an infinite behavior pattern in the execution trace of
    its input.

    By doing this it bypasses the conventional feedback loop where the input program behaves in the opposite way of whatever the simulating halt
    decider decides.

    This also allows it to ignore its own behavior in the execution trace
    that it analyzes because a pure simulator cannot have any possible
    effect on the behavior of its input.

    This also provides an objective and unbiased measure of non-halting
    behavior. Any input to a simulating halt decider that never halts unless
    its simulation is aborted is an input that never halts.


    --
    Copyright 2021 Pete Olcott

    "Great spirits have always encountered violent opposition from mediocre
    minds." Einstein

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