• Re: DDD incorrectly emulated by HHH is incorrectly rejected as non-halt

    From Richard Damon@21:1/5 to olcott on Wed Jul 17 19:56:23 2024
    On 7/17/24 9:04 AM, olcott wrote:
    On 7/17/2024 1:52 AM, Mikko wrote:
    On 2024-07-16 18:18:07 +0000, olcott said:

    On 7/16/2024 2:57 AM, Mikko wrote:
    On 2024-07-15 13:43:34 +0000, olcott said:

    On 7/15/2024 3:17 AM, Mikko wrote:
    On 2024-07-14 14:50:47 +0000, olcott said:

    On 7/14/2024 5:09 AM, Mikko wrote:
    On 2024-07-12 14:56:05 +0000, olcott said:

    We stipulate that the only measure of a correct emulation is the >>>>>>>>> semantics of the x86 programming language.

    _DDD()
    [00002163] 55         push ebp      ; housekeeping >>>>>>>>> [00002164] 8bec       mov ebp,esp   ; housekeeping
    [00002166] 6863210000 push 00002163 ; push DDD
    [0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
    [00002170] 83c404     add esp,+04
    [00002173] 5d         pop ebp
    [00002174] c3         ret
    Size in bytes:(0018) [00002174]

    When N steps of DDD are emulated by HHH according to the
    semantics of the x86 language then N steps are emulated correctly. >>>>>>>>>
    When we examine the infinite set of every HHH/DDD pair such that: >>>>>>>>> HHH₁ one step of DDD is correctly emulated by HHH.
    HHH₂ two steps of DDD are correctly emulated by HHH.
    HHH₃ three steps of DDD are correctly emulated by HHH.
    ...
    HHH∞ The emulation of DDD by HHH never stops running.

    The above specifies the infinite set of every HHH/DDD pair
    where 1 to infinity steps of DDD are correctly emulated by HHH. >>>>>>>>
    You should use the indices here, too, e.g., "where 1 to infinity >>>>>>>> steps of
    DDD₁ are correctly emulated by HHH₃" or whatever you mean. >>>>>>>>

    DDD is the exact same fixed constant finite string that
    always calls HHH at the same fixed constant machine
    address.

    If the function called by DDD is not part of the input then the
    input does
    not specify a behaviour and the question whether DDD halts is
    ill-posed.


    We don't care about whether HHH halts. We know that
    HHH halts or fails to meet its design spec.

    We are only seeing if DDD correctly emulated by HHH
    can can possibly reach its own final state.

    HHH does not see even that. It only sees whther that it does not
    emulate
    DDD to its final state.

    No. HHH is not judging whether or not itself is a correct
    emulator. The semantics of the x86 instructions that emulates
    prove that its emulation is correct.

    The semantics does not prove. Only a proof would prove.


    Nothing besides the semantics of English proves that
    a kitten is not any type of 15 story office building.

    _DDD()
    [00002163] 55         push ebp      ; housekeeping
    [00002164] 8bec       mov ebp,esp   ; housekeeping
    [00002166] 6863210000 push 00002163 ; push DDD
    [0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
    [00002170] 83c404     add esp,+04
    [00002173] 5d         pop ebp
    [00002174] c3         ret
    Size in bytes:(0018) [00002174]

    DDD emulated by HHH according to the semantic meaning of
    its x86 instructions never stop running unless aborted.



    Wrong, EVERY DDD that is calls an HHH that any copy of it returns from
    the call HHH(DDD) to any caller makes a DDD that halts.

    Yes, the HHH can never reach that state in its emulation, but DDD gets
    there.

    You are just proving you are a stupid liar that doesn't know what he is
    talking about.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Fri Jul 19 11:28:18 2024
    On 7/19/24 9:48 AM, olcott wrote:
    On 7/19/2024 2:30 AM, Mikko wrote:
    On 2024-07-18 13:36:53 +0000, olcott said:

    On 7/18/2024 2:55 AM, Mikko wrote:
    On 2024-07-17 13:14:43 +0000, olcott said:

    On 7/17/2024 2:08 AM, Mikko wrote:
    On 2024-07-16 14:46:40 +0000, olcott said:

    On 7/16/2024 2:18 AM, Mikko wrote:
    On 2024-07-15 13:32:27 +0000, olcott said:

    On 7/15/2024 2:57 AM, Mikko wrote:
    On 2024-07-14 14:48:05 +0000, olcott said:

    On 7/14/2024 3:49 AM, Mikko wrote:
    On 2024-07-13 12:18:27 +0000, olcott said:

    When the source of your disagreement is your own ignorance >>>>>>>>>>> then your disagreement has no actual basis.

    *You can comprehend this is a truism or fail to*
    *comprehend it disagreement is necessarily incorrect*
    Any input that must be aborted to prevent the non
    termination of HHH necessarily specifies non-halting
    behavior or it would never need to be aborted.

    Disagreeing with the above is analogous to disagreeing
    with arithmetic.

    A lame analogy. A better one is: 2 + 3 = 5 is a proven theorem >>>>>>>>>> just
    like the uncomputability of halting is.

    The uncomputability of halting is only proven when the problem >>>>>>>>> is framed this way: HHH is required to report on the behavior >>>>>>>>> of an input that was defined to do exactly the opposite of
    whatever DDD reports.

    No, it is proven about the halting problem as that problem is.

    Which is simply a logical impossibility

    Yes, a halting decider is a logical impossibility, as can be and has >>>>>> been proven.

    If it is a logical impossibility then it places no
    actual limit on computation otherwise we would have
    "the CAD problem" of the logical impossibility of making
    a CAD system that correctly draws a square circle.

    A logical impossibility does place a limit on computation.
    Otherwise it would be possible to build a CAD system that
    can correctly draw a square circle.

    Of the set of possible things TM's can do them all.

    Depends on the meanings of "possible" and "thing". Of things other than
    computation no TM can do any. A Turing machine can determine whether
    a sentence of Presburger arithmetic is provable but no Turing machine
    can determine whether a sentence of Peano arithmetic is provable.


    Some undecidable expressions are only undecidable because
    they are self contradictory. In other words they are undecidable
    because there is something wrong with them.

    So, you ADMIT that there actually are some correct expression that are undecable, and only SOME are based on wrong statements.


    The Liar Paradox: "This sentence is not true"
    (is neither true nor false) and the HP proof are that way,
    yet, only when we expect a decider to return the halt status
    of an input that does that opposite of whatever value the
    decider returns.

    typedef void (*ptr)();
    int HHH(ptr P);

    int DD()
    {
      int Halt_Status = HHH(DD);
      if (Halt_Status)
        HERE: goto HERE;
      return Halt_Status;
    }

    int main()
    {
      DD();
    }

    *When we understand that*
    (a) The halt decider is not allowed to report on the computation
    that it is contained within. Then the behavior of the directly
    executed DD() is moot.

    Says who? That is your lie.

    The decider MUST report on the computation its input describes to be a
    Halt Decider, even if that input includes a description of itself.


    (b) The self-contradictory part of the input is unreachable from
    the emulated DD then a simulating partial halt decider does
    correctly compute the mapping from the input finite string to
    the non-halting behavior of this finite string.


    No, it is unrachable by the emulation of the decider, but not by the
    behavior of the machine described, this is your fundamental confusion
    because you can't seem to tell the difference between the full reality
    and a partial observation of it.

    int main { DD(); } calls HHH(DD) that must abort the emulation
    of its input or HHH, emulated DD and executed DD never stop
    running.


    But HHH is only the program that it actually is. And if HHH meets the requirements to be a decider, it WILL aborts is simulation and return
    and thus DDD will returm.

    Your "doesn't abort" case doesn't actually exist in the actual HHH you
    are claiming, it is just a lie that you make up.

    IT seems you don't seem to understand that essential fact about
    programs, they aren't one until coded, and then they do exactly what
    there coding says they will do.

    There is no HHH that actually "correctly emulates" its inpout to the
    point of getting an answer and also is a decider, so you claims assuming
    such a machine are just LIES.

    Your whole world seems to be based on similar lies, where you just
    assume things must exists because you think they should, which has just
    turned your into an ignorant pathological lying idiot.

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