• Olcott's Mmajor Malfunction

    From Mr Flibble@21:1/5 to All on Thu Aug 7 22:01:50 2025
    Olcott's major malfunction as far as the Halting Problem is concerned is
    his inability to recognise the difference between (and/or his conflation
    of) *execution* with *computation*.

    /Flibble

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mr Flibble@21:1/5 to olcott on Thu Aug 7 22:23:28 2025
    On Thu, 07 Aug 2025 17:15:12 -0500, olcott wrote:

    On 8/7/2025 5:01 PM, Mr Flibble wrote:
    Olcott's major malfunction as far as the Halting Problem is concerned
    is his inability to recognise the difference between (and/or his
    conflation of) *execution* with *computation*.

    /Flibble

    We spent years going over this point in this forum. https://en.wikipedia.org/wiki/Computable_function

    You only think in terms of execution hence the erroneous recursion
    manifesting (and which you "abort") in your HHH.

    /Flibble

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mr Flibble@21:1/5 to olcott on Fri Aug 8 00:06:32 2025
    On Thu, 07 Aug 2025 18:36:48 -0500, olcott wrote:

    On 8/7/2025 5:23 PM, Mr Flibble wrote:
    On Thu, 07 Aug 2025 17:15:12 -0500, olcott wrote:

    On 8/7/2025 5:01 PM, Mr Flibble wrote:
    Olcott's major malfunction as far as the Halting Problem is concerned
    is his inability to recognise the difference between (and/or his
    conflation of) *execution* with *computation*.

    /Flibble

    We spent years going over this point in this forum.
    https://en.wikipedia.org/wiki/Computable_function

    You only think in terms of execution hence the erroneous recursion
    manifesting (and which you "abort") in your HHH.

    /Flibble

    That no one ever thought of a simulating halt decider based on a UTM
    before is why there is no separate notion of a directly executing Turing machine.

    Turing Machine Linz Ĥ applied to its own machine description ⟨Ĥ⟩ Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    Ĥ applied to ⟨Ĥ⟩ is directly executing.
    ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H is not directly executing.

    A simulating halt decider (even a partial one) cannot exist because the self-referential nature of the diagonalization proof (which is a valid
    proof) guarantees that the halt decider cannot return a halting decision
    to its caller — it gets stuck in infinite recursion instead. This means it fails to qualify as a halt decider at all.

    Your workaround of “aborting the simulation” merely sidesteps the problem: you end up with the same HHH behaving differently depending on where it
    appears in the execution (simulator) call stack. That’s not a solution — it’s a dodge.

    /Flibble

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Thu Aug 7 20:58:46 2025
    On 8/7/25 6:15 PM, olcott wrote:
    On 8/7/2025 5:01 PM, Mr Flibble wrote:
    Olcott's major malfunction as far as the Halting Problem is concerned is
    his inability to recognise the difference between (and/or his conflation
    of) *execution* with *computation*.

    /Flibble

    We spent years going over this point in this forum. https://en.wikipedia.org/wiki/Computable_function


    But the problem is, the Halting Function isn't a computable function.

    And you don't understand that the input to the Turing Machhine, while is
    a finite string, is often just the representation for something else,
    and the correct answer is based on that other thing.

    And thus the domain for the Halting Function, that the Halt Decider is
    trying to compute, *IS* based on the behavior of the Turing Machine and
    input given to it, and that the input given to the Halt Decider
    semantically means that same program and behavior, not the partial
    simulation done by the decider.

    Since it is shown, and you have even admitted, that no decider can
    compute that Function, it just isn't a Computable Function, which
    doesn't mean you get to change the requirements, as that would just be
    lying, something you have shown you like to do.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Thu Aug 7 21:33:10 2025
    On 8/7/25 7:36 PM, olcott wrote:
    On 8/7/2025 5:23 PM, Mr Flibble wrote:
    On Thu, 07 Aug 2025 17:15:12 -0500, olcott wrote:

    On 8/7/2025 5:01 PM, Mr Flibble wrote:
    Olcott's major malfunction as far as the Halting Problem is concerned
    is his inability to recognise the difference between (and/or his
    conflation of) *execution* with *computation*.

    /Flibble

    We spent years going over this point in this forum.
    https://en.wikipedia.org/wiki/Computable_function

    You only think in terms of execution hence the erroneous recursion
    manifesting (and which you "abort") in your HHH.

    /Flibble

    That no one ever thought of a simulating halt decider
    based on a UTM before is why there is no separate notion
    of a directly executing Turing machine.

    The problem is you can't do it. as to be a UTM, it can't abort its
    simulation, and to be a decider, it MUST abort its simulation of some
    inputs.

    All you are showing is that you don't know what the words mean.


    Turing Machine Linz Ĥ applied to its own machine description ⟨Ĥ⟩
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

    Ĥ applied to ⟨Ĥ⟩ is directly executing.
    ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H is not directly executing.



    Right, but since H (and Ĥ.embedded_H) aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩,
    that simulation doesn't define the behavior of that input.

    In fact, by the definition of a Halt Decider, the only semantic
    meaningful definition of the behavior of ⟨Ĥ⟩ ⟨Ĥ⟩ is the behavior of Ĥ applied to ⟨Ĥ⟩, the direct execution of the machine represented by the input, and anything else is just a demonstration of ignorance and duplicity.

    Sorry, you are just proving you are just a ignorant pathological liar
    that doesn't know the meaning of his words, and just doesn't care.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mikko@21:1/5 to olcott on Sat Aug 9 10:51:15 2025
    On 2025-08-07 23:36:48 +0000, olcott said:

    On 8/7/2025 5:23 PM, Mr Flibble wrote:
    On Thu, 07 Aug 2025 17:15:12 -0500, olcott wrote:

    On 8/7/2025 5:01 PM, Mr Flibble wrote:
    Olcott's major malfunction as far as the Halting Problem is concerned
    is his inability to recognise the difference between (and/or his
    conflation of) *execution* with *computation*.

    /Flibble

    We spent years going over this point in this forum.
    https://en.wikipedia.org/wiki/Computable_function

    You only think in terms of execution hence the erroneous recursion
    manifesting (and which you "abort") in your HHH.

    /Flibble

    That no one ever thought of a simulating halt decider
    based on a UTM before is why there is no separate notion
    of a directly executing Turing machine.

    In fact direct execution is just another simulation. A text string
    does not execute by itself. In order to have an exectuion someone
    or something must interprete the text and act accordingly.

    --
    Mikko

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mikko@21:1/5 to olcott on Sat Aug 9 10:48:43 2025
    On 2025-08-07 22:15:12 +0000, olcott said:

    On 8/7/2025 5:01 PM, Mr Flibble wrote:
    Olcott's major malfunction as far as the Halting Problem is concerned is
    his inability to recognise the difference between (and/or his conflation
    of) *execution* with *computation*.

    /Flibble

    We spent years going over this point in this forum. https://en.wikipedia.org/wiki/Computable_function

    Apparently without achieving anything.

    --
    Mikko

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Heathfield@21:1/5 to olcott on Sat Aug 9 15:35:21 2025
    On 09/08/2025 15:31, olcott wrote:
    On 8/9/2025 2:48 AM, Mikko wrote:
    On 2025-08-07 22:15:12 +0000, olcott said:

    <snip>

    We spent years going over this point in this forum.
    https://en.wikipedia.org/wiki/Computable_function

    Apparently without achieving anything.


    Only because people here are dead set on rebuttal
    even at the expense of truth.

    The behavior of DD() is not the behavior that HHH
    can possibly see.

    Okay, so you concede that HHH is not fit for purpose.

    Took you long enough.

    HHH can only see the behavior that
    its actual input actually specifies as measured by
    DD correctly simulated by HHH.

    Requiring HHH to report on anything besides the behavior
    that its actual input actually specifies is the same as
    requiring sum(3,2) to report on the sum of 6 + 3.

    In other words, simulation doesn't work.

    You've tried it, and to be fair you've tried *hard*, but at the
    end of the line it simply can't do the job, and that's that, yes?

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Heathfield@21:1/5 to olcott on Sat Aug 9 15:49:45 2025
    On 09/08/2025 15:36, olcott wrote:

    <snip>

    It is incorrect for HHH(DD) to report on the behavior
    of DD() after HHH has aborted its simulation.

    Fair enough. Unfortunately, it is also incorrect for HHH(DD) not
    to. HHH can't win.

    Clearly, simulation is the wrong approach.

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Heathfield@21:1/5 to olcott on Sat Aug 9 16:15:19 2025
    On 09/08/2025 16:02, olcott wrote:
    It has always been a false assumption that a halt
    decider must report on the behavior of the direct
    execution of a Turing machine.

    Unsupported claim.

    I will agree, though, that it has always been a false assumption
    that a halt decider /can/ always report correctly on the
    behaviour of any arbitrary Turing Machine.

    Proof: Turing's paper.

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Heathfield@21:1/5 to olcott on Sat Aug 9 16:17:56 2025
    On 09/08/2025 16:09, olcott wrote:
    On 8/9/2025 9:49 AM, Richard Heathfield wrote:
    On 09/08/2025 15:36, olcott wrote:

    <snip>

    It is incorrect for HHH(DD) to report on the behavior
    of DD() after HHH has aborted its simulation.

    Fair enough. Unfortunately, it is also incorrect for HHH(DD)
    not to. HHH can't win.

    Clearly, simulation is the wrong approach.


    <MIT Professor Sipser agreed to ONLY these verbatim words

    Oh, he's back, is he?

    What he agreed to is irrelevant. What matters is what HHH
    returns... except that it doesn't, because we know it gets it wrong.

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Heathfield@21:1/5 to olcott on Sat Aug 9 16:49:02 2025
    On 09/08/2025 16:22, olcott wrote:
    On 8/9/2025 10:15 AM, Richard Heathfield wrote:
    On 09/08/2025 16:02, olcott wrote:
    It has always been a false assumption that a halt
    decider must report on the behavior of the direct
    execution of a Turing machine.

    Unsupported claim.

    I will agree, though, that it has always been a false
    assumption that a halt decider /can/ always report correctly on
    the behaviour of any arbitrary Turing Machine.

    Proof: Turing's paper.


    It is dishonest for you to disagree prior to
    looking at all of what I said when your
    disagreement is anchored in a false assumption.

    My disagreement is anchored in Turing's proof. I understand that
    you have always steered clear of claiming that Turing was
    mistaken. Are you now making that claim?


    Computable functions

    The halt decider for DD is not a computable function.


    have never been allowed to
    report on non-inputs.

    How can any function, computable or otherwise report on a non-input?

    That you keep insisting
    that they must proves your lack of attention
    to detail.

    Not at all, for two reasons:

    (1) DD is clearly an input;
    (2) HHH is clearly incomputable. (A working HHH, I mean. Not one
    that manifestly fails to work.)

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Heathfield@21:1/5 to olcott on Sat Aug 9 16:42:52 2025
    On 09/08/2025 16:16, olcott wrote:
    On 8/9/2025 9:35 AM, Richard Heathfield wrote:
    On 09/08/2025 15:31, olcott wrote:

    <snip>


    The behavior of DD() is not the behavior that HHH
    can possibly see.

    Okay, so you concede that HHH is not fit for purpose.


    *Not at all*

    No surprise there.

    But all you have is a halt decider that satisfies *you*.

    Great. What do you plan to do with it?

    Because what you won't be able to do is satisfy anyone else that
    you have anything even remotely worthwhile. 22 years of futile
    debate should have taught you that, at least.

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From joes@21:1/5 to All on Sat Aug 9 16:35:36 2025
    Am Sat, 09 Aug 2025 10:16:37 -0500 schrieb olcott:
    On 8/9/2025 9:35 AM, Richard Heathfield wrote:
    On 09/08/2025 15:31, olcott wrote:

    The behavior of DD() is not the behavior that HHH can possibly see.
    Okay, so you concede that HHH is not fit for purpose.
    It has always been a false assumption that a halt decider must report on
    the behavior of the direct execution of a Turing machine.

    It's not an assumption. It's the problem statement.
    And partial simulators *can* report on the direct execution of their
    input, like "Does it halt in n steps?".

    --
    Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
    It is not guaranteed that n+1 exists for every n.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to olcott on Sat Aug 9 17:53:59 2025
    On 8/9/25 10:36 AM, olcott wrote:
    On 8/9/2025 2:51 AM, Mikko wrote:
    On 2025-08-07 23:36:48 +0000, olcott said:

    On 8/7/2025 5:23 PM, Mr Flibble wrote:
    On Thu, 07 Aug 2025 17:15:12 -0500, olcott wrote:

    On 8/7/2025 5:01 PM, Mr Flibble wrote:
    Olcott's major malfunction as far as the Halting Problem is concerned >>>>>> is his inability to recognise the difference between (and/or his
    conflation of) *execution* with *computation*.

    /Flibble

    We spent years going over this point in this forum.
    https://en.wikipedia.org/wiki/Computable_function

    You only think in terms of execution hence the erroneous recursion
    manifesting (and which you "abort") in your HHH.

    /Flibble

    That no one ever thought of a simulating halt decider
    based on a UTM before is why there is no separate notion
    of a directly executing Turing machine.

    In fact direct execution is just another simulation. A text string
    does not execute by itself. In order to have an exectuion someone
    or something must interprete the text and act accordingly.


    It is incorrect for HHH(DD) to report on the behavior
    of DD() after HHH has aborted its simulation.


    Why?

    Since the behavior in question is the behavior of the program, which is
    an objective measure not dependent on who looks at it.

    The simulaiton by HHH, since it can decide when to abort, isn't an
    objective measure, but a subjective measure, and thus not a valid measure.

    This is the same thing as believing that one never needs
    to eat entirely on the basis of knowing that one will not
    need to eat after one has eaten. This misconception will
    cause death by starvation.


    Nope, as that is a discussion of a transiant process, while programs are deterministic processes.

    You are just stuck in another of your category errors, not understanding
    the meaning of your words.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mikko@21:1/5 to olcott on Sun Aug 10 12:29:37 2025
    On 2025-08-09 14:36:40 +0000, olcott said:

    On 8/9/2025 2:51 AM, Mikko wrote:
    On 2025-08-07 23:36:48 +0000, olcott said:

    On 8/7/2025 5:23 PM, Mr Flibble wrote:
    On Thu, 07 Aug 2025 17:15:12 -0500, olcott wrote:

    On 8/7/2025 5:01 PM, Mr Flibble wrote:
    Olcott's major malfunction as far as the Halting Problem is concerned >>>>>> is his inability to recognise the difference between (and/or his
    conflation of) *execution* with *computation*.

    /Flibble

    We spent years going over this point in this forum.
    https://en.wikipedia.org/wiki/Computable_function

    You only think in terms of execution hence the erroneous recursion
    manifesting (and which you "abort") in your HHH.

    /Flibble

    That no one ever thought of a simulating halt decider
    based on a UTM before is why there is no separate notion
    of a directly executing Turing machine.

    In fact direct execution is just another simulation. A text string
    does not execute by itself. In order to have an exectuion someone
    or something must interprete the text and act accordingly.

    It is incorrect for HHH(DD) to report on the behavior
    of DD() after HHH has aborted its simulation.

    It is incorrect to report anything other than what the problem
    statement requires to be reported.

    --
    Mikko

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mikko@21:1/5 to olcott on Sun Aug 10 12:41:31 2025
    On 2025-08-09 15:48:11 +0000, olcott said:

    On 8/9/2025 10:42 AM, Richard Heathfield wrote:
    On 09/08/2025 16:16, olcott wrote:
    On 8/9/2025 9:35 AM, Richard Heathfield wrote:
    On 09/08/2025 15:31, olcott wrote:

    <snip>


    The behavior of DD() is not the behavior that HHH
    can possibly see.

    Okay, so you concede that HHH is not fit for purpose.


    *Not at all*

    No surprise there.

    Because I do not simply ignore the reasoning
    that disagrees with me, (as you do).

    You do ignore more often you don't.

    I prove that this reasoning is incorrect and
    you simply ignore this proof.

    You never prove.

    --
    Mikko

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Heathfield@21:1/5 to Mikko on Sun Aug 10 10:55:43 2025
    On 10/08/2025 10:29, Mikko wrote:
    On 2025-08-09 14:36:40 +0000, olcott said:

    <snip>

    It is incorrect for HHH(DD) to report on the behavior
    of DD() after HHH has aborted its simulation.

    It is incorrect to report anything other than what the problem
    statement requires to be reported.

    I expect he meant to write "impossible". After all, HHH can
    hardly keep simulating after it's returned.

    And it's a shame, because if it could it would see all that juicy
    reversal of fortunes, and maybe change its mind about whether DD
    halts...or not, because DD won't make up its mind until after HHH
    does.

    Bearing in mind that olcott has form for giving words new
    meanings at the drop of a hat, it seems only fair to interpret
    the man's words with our own (charitable) meanings when it seems
    appropriate.

    Here, "impossible" is a good fit.

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Heathfield@21:1/5 to Mikko on Sun Aug 10 11:00:49 2025
    On 10/08/2025 10:41, Mikko wrote:
    On 2025-08-09 15:48:11 +0000, olcott said:

    On 8/9/2025 10:42 AM, Richard Heathfield wrote:
    On 09/08/2025 16:16, olcott wrote:
    On 8/9/2025 9:35 AM, Richard Heathfield wrote:
    On 09/08/2025 15:31, olcott wrote:

    <snip>


    The behavior of DD() is not the behavior that HHH
    can possibly see.

    Okay, so you concede that HHH is not fit for purpose.


    *Not at all*

    No surprise there.

    Because I do not simply ignore the reasoning
    that disagrees with me, (as you do).

    You do ignore more often you don't.

    I prove that this reasoning is incorrect and
    you simply ignore this proof.

    You never prove.

    It's probably fair to interpret his "proof" or "prove" as
    "attempt to explain". It's a reasonably accurate interpretation
    of what he's doing when he uses the word.

    As for rigour, what he says is, in his eyes, self-evidently true
    because it's him saying it. And if he can see that, so should
    you, which is what makes you dishonest when you don't.

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within

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