On 8/22/2022 12:53 PM, Mr Flibble wrote:
> On Mon, 22 Aug 2022 12:50:20 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 8/22/2022 12:43 PM, Mr Flibble wrote:
>>> On Mon, 22 Aug 2022 12:39:41 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 8/22/2022 12:15 PM, Mr Flibble wrote:
>>>>> On Mon, 22 Aug 2022 12:04:11 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 8/22/2022 11:21 AM, Mr Flibble wrote:
>>>>>>> On Mon, 22 Aug 2022 09:31:47 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> On 8/21/2022 10:37 PM, Richard Damon wrote:
>>>>>>>>> On 8/21/22 11:27 PM, olcott wrote:
>>>>>>>>>> On 8/21/2022 10:14 PM, Richard Damon wrote:
>>>>>>>>>>> On 8/21/22 9:37 PM, olcott wrote:
>>>>>>>>>>>> On 8/21/2022 8:04 PM, Richard Damon wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 8/21/22 8:45 PM, olcott wrote:
>>>>>>>>>>>>>> On 8/21/2022 1:04 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 8/21/22 11:36 AM, olcott wrote:
>>>>>>>>>>>>>>>> On 8/21/2022 10:16 AM, Shvili, the Kookologist wrote:
>>>>>>>>>>>>>>>>> On Sat, 20 Aug 2022 16:01:31 -0500, in article
>>>>>>>>>>>>>>>>> <crudnRbncP4E1pz- nZ2dnZfqlJzNnZ2d@giganews.com>,
>>>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> [snip]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It is common knowledge that [...]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Have you noticed that almost every time you use this
>>>>>>>>>>>>>>>>> phrase, you're
>>>>>>>>>>>>>>>>> wrong?
>>>>>>>>>>>>>>>>> So also this time.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> [...] the correct and complete simulation of a
>>>>>>>>>>>>>>>>>> machine description [...]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Machine descriptions are never simulated -- they're
>>>>>>>>>>>>>>>>> just sequences of symbols.
>>>>>>>>>>>>>>>>> and don't have any defined behaviour. The machines
>>>>>>>>>>>>>>>>> they *represent*
>>>>>>>>>>>>>>>>> may be
>>>>>>>>>>>>>>>>> simulated.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> [...] always provides the actual behavior specified
>>>>>>>>>>>>>>>>>> by this machine description.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This is almost, but not quite, correct (if you fix it
>>>>>>>>>>>>>>>>> according to the
>>>>>>>>>>>>>>>>> previous paragraph). It would have been completely
>>>>>>>>>>>>>>>>> correct, if it weren't
>>>>>>>>>>>>>>>>> for the fact that you're using an utterly bizarre
>>>>>>>>>>>>>>>>> meaning for the phrase
>>>>>>>>>>>>>>>>> "the actual behavior specified by this machine
>>>>>>>>>>>>>>>>> description".
>>>>>>>>>>>>>>>>>> That you and others reject this when it is applied to
>>>>>>>>>>>>>>>>>> my simulating halt
>>>>>>>>>>>>>>>>>> decider implicitly rejects the notion of a UTM. Since
>>>>>>>>>>>>>>>>>> you and others do
>>>>>>>>>>>>>>>>>> accept the notion of a UTM, I have just proven that
>>>>>>>>>>>>>>>>>> your reasoning is
>>>>>>>>>>>>>>>>>> incoherent and/or inconsistent.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Let M be a given machine, with machine description
>>>>>>>>>>>>>>>>> [M], and let w be
>>>>>>>>>>>>>>>>> a given input tape, with tape description [w]. Then
>>>>>>>>>>>>>>>>> the "simulation"
>>>>>>>>>>>>>>>>> UTM([M],[w]) has exactly the same result (i.e. exactly
>>>>>>>>>>>>>>>>> the same behaviour)
>>>>>>>>>>>>>>>>> as the direct computation M(w). This is actually the
>>>>>>>>>>>>>>>>> definition of a UTM.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Another way of expressing this is: M(w) and
>>>>>>>>>>>>>>>>> UTM([M],[w]) compute the same
>>>>>>>>>>>>>>>>> partial function.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You have made it abundantly clear that when you say
>>>>>>>>>>>>>>>>> "the actual behavior
>>>>>>>>>>>>>>>>> specified by this machine description", you do *not*
>>>>>>>>>>>>>>>>> mean "the actual
>>>>>>>>>>>>>>>>> behavior specified by this machine description",
>>>>>>>>>>>>>>>>> because that's simply
>>>>>>>>>>>>>>>>> the behaviour of M(w). What you *do* mean is "the
>>>>>>>>>>>>>>>>> behaviour of your
>>>>>>>>>>>>>>>>> particular, broken and incomplete, quasi-simulation
>>>>>>>>>>>>>>>>> based on [M] and [w]".
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Why is it broken? Because it *doesn't* have the same
>>>>>>>>>>>>>>>>> behaviour as M
>>>>>>>>>>>>>>>>> (w),
>>>>>>>>>>>>>>>>> nor as UTM([M],[w]). A correct simulation *means* that
>>>>>>>>>>>>>>>>> it has the same
>>>>>>>>>>>>>>>>> behaviour as M(w).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Why is it incomplete? Because it aborts its
>>>>>>>>>>>>>>>>> "simulation" before it reaches
>>>>>>>>>>>>>>>>> a halting configuration of the machine represented by
>>>>>>>>>>>>>>>>> its input, and it
>>>>>>>>>>>>>>>>> does so on invalidly.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Why is it a quasi-simulation? Because it depends on
>>>>>>>>>>>>>>>>> external input that is
>>>>>>>>>>>>>>>>> contained in neither [M] nor [w]. You have said, on
>>>>>>>>>>>>>>>>> numerous occasions,
>>>>>>>>>>>>>>>>> that the behaviour of your "H(P,P)" depends on the
>>>>>>>>>>>>>>>>> specific memory location of "P". Well, then that
>>>>>>>>>>>>>>>>> location is an external input. Your H is
>>>>>>>>>>>>>>>>> *not* analogous to Linz' H([M],[w]).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This is the point where you usually barf up your
>>>>>>>>>>>>>>>>> stanza about how the
>>>>>>>>>>>>>>>>> behaviour of your "H(P,P)" cannot be expected to be
>>>>>>>>>>>>>>>>> computed "from the
>>>>>>>>>>>>>>>>> non-input P(P)". This is obviously idiotic, for the
>>>>>>>>>>>>>>>>> following reasons:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 1) A purported halt decider H([M],[w]) is *not*
>>>>>>>>>>>>>>>>> required to compute
>>>>>>>>>>>>>>>>> its
>>>>>>>>>>>>>>>>>     result *from* M(w), but to *match* M(w).
>>>>>>>>>>>>>>>>> Computing *from* M(w) would be
>>>>>>>>>>>>>>>>>     completely pointless, because the decider would
>>>>>>>>>>>>>>>>> already know the
>>>>>>>>>>>>>>>>> answer.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>     Since you seem unable to understand anything
>>>>>>>>>>>>>>>>> but arguments from
>>>>>>>>>>>>>>>>>     analogy, let me re-use one that you yourself
>>>>>>>>>>>>>>>>> have employed: Suppose
>>>>>>>>>>>>>>>>>     we want to construct an addition algorithm
>>>>>>>>>>>>>>>>> add(x,y). If you were
>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>     complain that add(5,7) cannot be required to
>>>>>>>>>>>>>>>>> compute its result
>>>>>>>>>>>>>>>>> "from
>>>>>>>>>>>>>>>>>     the non-input 12", you would, quite rightly, be
>>>>>>>>>>>>>>>>> regarded as a complete
>>>>>>>>>>>>>>>>>     nitwit. Can you now guess why you're
>>>>>>>>>>>>>>>>> universally regarded as a complete
>>>>>>>>>>>>>>>>>     nitwit?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2) The behaviour of UTM([M],[w]) is *defined* to match
>>>>>>>>>>>>>>>>> the behaviour of M(w),
>>>>>>>>>>>>>>>>>     and UTMs very evidently do exist. The
>>>>>>>>>>>>>>>>> information contained in [M] and [w]
>>>>>>>>>>>>>>>>>     is obviously enough to match the behaviour of
>>>>>>>>>>>>>>>>> M(w). The fact that your
>>>>>>>>>>>>>>>>>     "simulator" fails in this regard, is proof that
>>>>>>>>>>>>>>>>> your "simulator" is
>>>>>>>>>>>>>>>>>     defective -- *not* that you have discovered a
>>>>>>>>>>>>>>>>> "loop hole", or that halting
>>>>>>>>>>>>>>>>>     theorem is faulty, or anything of that kind --
>>>>>>>>>>>>>>>>> only that you're
>>>>>>>>>>>>>>>>> working
>>>>>>>>>>>>>>>>>     with a broken simulator.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE
>>>>>>>>>>>>>>>>>> THERE IS NO ERROR*
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> A lot of people have pointed out many kinds of errors
>>>>>>>>>>>>>>>>> in your reasoning.
>>>>>>>>>>>>>>>>> You usually respond with some form "proof by
>>>>>>>>>>>>>>>>> regurgitation". I expect you
>>>>>>>>>>>>>>>>> will do so to this post.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> When-so-ever a simulating halt decider (SHD)
>>>>>>>>>>>>>>>>>> correctly performs a partial simulation of its input
>>>>>>>>>>>>>>>>>> and the behavior of this partial simulation
>>>>>>>>>>>>>>>>>> correctly matches a non-halting behavior pattern
>>>>>>>>>>>>>>>>>> then the SHD halt decider can correctly report
>>>>>>>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> A non-halting behavior pattern is correct
>>>>>>>>>>>>>>>>>> when-so-ever matching this
>>>>>>>>>>>>>>>>>> behavior pattern proves that the correct and complete
>>>>>>>>>>>>>>>>>> simulation of the
>>>>>>>>>>>>>>>>>> input by SHD would never reach the final state of
>>>>>>>>>>>>>>>>>> this simulated input.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yeah, that's just a bunch of equivocations on
>>>>>>>>>>>>>>>>> "correctly", "its input",
>>>>>>>>>>>>>>>>> "non-halting behavior", and more.  Please learn to
>>>>>>>>>>>>>>>>> write clearly.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Also, could you *please* stop misreading Linz! He
>>>>>>>>>>>>>>>>> *doesn't* say that a TM
>>>>>>>>>>>>>>>>> halts, only if it enters a "final state". What he
>>>>>>>>>>>>>>>>> actually says is:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>      "A Turing machine is said to halt whenever it
>>>>>>>>>>>>>>>>> reaches a configuration
>>>>>>>>>>>>>>>>>      for which delta is not defined; this is
>>>>>>>>>>>>>>>>> possible because delta
>>>>>>>>>>>>>>>>> is a
>>>>>>>>>>>>>>>>>      partial function. In fact, we will assume
>>>>>>>>>>>>>>>>> that no transitions are
>>>>>>>>>>>>>>>>>      defined for any final state, so the Turing
>>>>>>>>>>>>>>>>> machine will halt whenever
>>>>>>>>>>>>>>>>>      it enters a final state."
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> So, for a general TM, there may well be configurations
>>>>>>>>>>>>>>>>> for which the TM
>>>>>>>>>>>>>>>>> halts in a non-final state. It is, on the other hand,
>>>>>>>>>>>>>>>>> understood that a TM
>>>>>>>>>>>>>>>>> *only* stops running if enters a configuration for
>>>>>>>>>>>>>>>>> which the transition
>>>>>>>>>>>>>>>>> function is undefined.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> "Final states" only concern the *interpretation* of
>>>>>>>>>>>>>>>>> the value of a computation -- *not* whether the TM
>>>>>>>>>>>>>>>>> halts or not.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This means that "halting" and "stops running" are the
>>>>>>>>>>>>>>>>> exact the same things.
>>>>>>>>>>>>>>>>> And obviously, "running" and "being simulated" are two
>>>>>>>>>>>>>>>>> entirely different
>>>>>>>>>>>>>>>>> things.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>    int Halt_Status = UTM(x, x);
>>>>>>>>>>>>>>>>    if (Halt_Status)
>>>>>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>>>>>>    return;
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The behavior of the actual input to the simulating halt
>>>>>>>>>>>>>>>> decider is the behavior of the above. Since C functions
>>>>>>>>>>>>>>>> do not actually have UTM's a more accurate way of
>>>>>>>>>>>>>>>> sayoing this is:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>    int Halt_Status = Simulate(x, x);
>>>>>>>>>>>>>>>>    if (Halt_Status)
>>>>>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>>>>>>    return;
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The behavior of UTM(P,P) or Simulate(P,P) is not the
>>>>>>>>>>>>>>>> behavior of the actual input to H(P,P) because it is
>>>>>>>>>>>>>>>> at a different point in the execution trace than
>>>>>>>>>>>>>>>> H(P,P).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Wrong, at least if H is supposed to be a Halt Decider.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You forget the question that the Halt Decider is being
>>>>>>>>>>>>>>> asked to solve, which is what the machine represented by
>>>>>>>>>>>>>>> its input would do.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is common knowledge that the correct and complete
>>>>>>>>>>>>>> simulation of a machine description always provides the
>>>>>>>>>>>>>> actual behavior specified by this machine description.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Right.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That you (and others such as Ben) reject that the correct
>>>>>>>>>>>>>> and complete simulation by H(P,P) of its input does
>>>>>>>>>>>>>> provide the actual behavior of this input also rejects
>>>>>>>>>>>>>> the notion of a UTM which you accept, thus you (and all
>>>>>>>>>>>>>> others holding this view such as Ben) contradict yourself
>>>>>>>>>>>>>> (themselves).
>>>>>>>>>>>>>
>>>>>>>>>>>>> So, why do you reject the actual correct and complete
>>>>>>>>>>>>> simulation of the input to H when done by an actual pure
>>>>>>>>>>>>> simulator/UTM?
>>>>>>>>>>>> As long as it is done at the exact point in the execution
>>>>>>>>>>>> trace as H(P,P) then it is fine, otherwise it is not the
>>>>>>>>>>>> same as the simulation by H(P,P).
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The simulation of the input to H(P,P) is the simulation of
>>>>>>>>>>> the instruction sequence specified by the code of P (and the
>>>>>>>>>>> routines it calls) and has ZERO dependency on what happened
>>>>>>>>>>> before that call
>>>>>>>>>>
>>>>>>>>>> main()
>>>>>>>>>> {
>>>>>>>>>>    P(P); // depends on the return value from H(P,P);
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> The input to H(P,P) that H correctly simulates cannot
>>>>>>>>>> possibly depend on the return value from H because this
>>>>>>>>>> return value is unreachable by P:
>>>>>>>>>
>>>>>>>>> But it NEEDS to. That fact that it can't get the needed value
>>>>>>>>> because of the limitation of your algorithm, doesn't mean it
>>>>>>>>> gets to ignore it.
>>>>>>>>>
>>>>>>>>> Not, Mr Flibble has shown a way that H CAN determine the
>>>>>>>>> behavior of P based on the return value of H, even though H
>>>>>>>>> can simulate the path through itself.
>>>>>>>>>
>>>>>>>>> (As I pointed out a long time ago too).
>>>>>>>>
>>>>>>>> Every function that is called in infinite recursion cannot
>>>>>>>> possibly correctly return to its caller. People that believe
>>>>>>>> that it can are as wrong as if they disagreed with arithmetic.
>>>>>>>>
>>>>>>>
>>>>>>> Your thinking isn't joined up. The Flibble Signaling Halt
>>>>>>> Decider (TM) is *not* infinitely recursive (as you have been
>>>>>>> told many times) so of course it is quite valid for it to
>>>>>>> return a value to its caller. The only thing that suffers from
>>>>>>> infinite recursion is your broken mess.
>>>>>>>>
>>>>>>>> If computer science says that a function called in finite
>>>>>>>> recursion must return to its caller then computer science is
>>>>>>>> wrong, one might as well have said the cats must be dogs.
>>>>>>>
>>>>>>> I assume you meant "infinite recursion". A function that
>>>>>>> returns a value to its caller is *by definition* not infinitely
>>>>>>> recursive.
>>>>>>>
>>>>>>> The Flibble Signaling Halt Decider (TM) just works, your mess
>>>>>>> does not.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> You claim to be a "computer scientist" yet do not even understand
>>>>>> the concept of unreachable code:
>>>>>>
>>>>>> void P(ptr x)
>>>>>> {
>>>>>> int Halt_Status = H(x, x);
>>>>>> if (Halt_Status)
>>>>>> HERE: goto HERE;
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>> }
>>>>>>
>>>>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>>>>>> (b) that simulates P(P) that calls a simulated H(P,P)
>>>>>> (c) that simulates P(P) that calls a simulated H(P,P)
>>>>>> (d) that simulates P(P) that calls a simulated H(P,P)...
>>>>>> *Until H aborts its simulation*
>>>>>
>>>>> Virtually every reply you make now totally ignores what you are
>>>>> replying to and instead is just regurgitation of the the same old
>>>>> shit.
>>>>>
>>>>> I have shown on several occasions in replies to you that I fully
>>>>> understand the concept of unreachable code.
>>>>>
>>>>> Again: the Flibble Signaling Halt Decider (TM) is *NOT* recursive
>>>>> so your traces don't apply to it, your traces only apply to your
>>>>> broken mess which has to "abort" the infinite recursion which is
>>>>> YOUR design mistake.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> Although H(P,P) does recognize and abort the simulation of its
>>>> input before the first recursive call is invoked, it remains an
>>>> easily verified fact that P specifies infinitely recursive
>>>> simulation to every simulating halt decider.
>>>
>>> Obviously not a verified fact given the Flibble Signaling Halt
>>> Decider (TM) is an example of a simulating halt decider that is
>>> *not* recursive ergo there is no recursive simulation: instead
>>> there is a forking simulation that allows the decider to return a
>>> value to its caller in each fork.
>>>
>>> /Flibble
>>>
>>>
>>
>> When H(P,P) simulates exactly what its input specifies:
>> no more and no less then this behavior results:
>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>> (b) that simulates P(P) that calls a simulated H(P,P)
>> (c) that simulates P(P) that calls a simulated H(P,P)
>> (d) that simulates P(P) that calls a simulated H(P,P)...
>> *Until H aborts its simulation*
>>
>> When H(P,P) simulates anything besides exactly what its input
>> specifies then its simulation is incorrect.
>
> Nope, the definition of a halt decider does not specify that a
> simulating halt decider must be recursive in nature.
>

On Mon, 22 Aug 2022 13:02:07 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 8/22/2022 12:53 PM, Mr Flibble wrote:
> > On Mon, 22 Aug 2022 12:50:20 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 8/22/2022 12:43 PM, Mr Flibble wrote:
> >>> On Mon, 22 Aug 2022 12:39:41 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 8/22/2022 12:15 PM, Mr Flibble wrote:
> >>>>> On Mon, 22 Aug 2022 12:04:11 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> On 8/22/2022 11:21 AM, Mr Flibble wrote:
> >>>>>>> On Mon, 22 Aug 2022 09:31:47 -0500
> >>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>
> >>>>>>>> On 8/21/2022 10:37 PM, Richard Damon wrote:
> >>>>>>>>> On 8/21/22 11:27 PM, olcott wrote:
> >>>>>>>>>> On 8/21/2022 10:14 PM, Richard Damon wrote:
> >>>>>>>>>>> On 8/21/22 9:37 PM, olcott wrote:
> >>>>>>>>>>>> On 8/21/2022 8:04 PM, Richard Damon wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On 8/21/22 8:45 PM, olcott wrote:
> >>>>>>>>>>>>>> On 8/21/2022 1:04 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>> On 8/21/22 11:36 AM, olcott wrote:
> >>>>>>>>>>>>>>>> On 8/21/2022 10:16 AM, Shvili, the Kookologist
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>> On Sat, 20 Aug 2022 16:01:31 -0500, in article
> >>>>>>>>>>>>>>>>> <crudnRbncP4E1pz- nZ2dnZfqlJzNnZ2d@giganews.com>,
> >>>>>>>>>>>>>>>>> olcott wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> [snip]
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> It is common knowledge that [...]
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Have you noticed that almost every time you use this
> >>>>>>>>>>>>>>>>> phrase, you're
> >>>>>>>>>>>>>>>>> wrong?
> >>>>>>>>>>>>>>>>> So also this time.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> [...] the correct and complete simulation of a
> >>>>>>>>>>>>>>>>>> machine description [...]
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Machine descriptions are never simulated -- they're
> >>>>>>>>>>>>>>>>> just sequences of symbols.
> >>>>>>>>>>>>>>>>> and don't have any defined behaviour. The machines
> >>>>>>>>>>>>>>>>> they *represent*
> >>>>>>>>>>>>>>>>> may be
> >>>>>>>>>>>>>>>>> simulated.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> [...] always provides the actual behavior specified
> >>>>>>>>>>>>>>>>>> by this machine description.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> This is almost, but not quite, correct (if you fix
> >>>>>>>>>>>>>>>>> it according to the
> >>>>>>>>>>>>>>>>> previous paragraph). It would have been completely
> >>>>>>>>>>>>>>>>> correct, if it weren't
> >>>>>>>>>>>>>>>>> for the fact that you're using an utterly bizarre
> >>>>>>>>>>>>>>>>> meaning for the phrase
> >>>>>>>>>>>>>>>>> "the actual behavior specified by this machine
> >>>>>>>>>>>>>>>>> description".
> >>>>>>>>>>>>>>>>>> That you and others reject this when it is applied
> >>>>>>>>>>>>>>>>>> to my simulating halt
> >>>>>>>>>>>>>>>>>> decider implicitly rejects the notion of a UTM.
> >>>>>>>>>>>>>>>>>> Since you and others do
> >>>>>>>>>>>>>>>>>> accept the notion of a UTM, I have just proven that
> >>>>>>>>>>>>>>>>>> your reasoning is
> >>>>>>>>>>>>>>>>>> incoherent and/or inconsistent.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Let M be a given machine, with machine description
> >>>>>>>>>>>>>>>>> [M], and let w be
> >>>>>>>>>>>>>>>>> a given input tape, with tape description [w]. Then
> >>>>>>>>>>>>>>>>> the "simulation"
> >>>>>>>>>>>>>>>>> UTM([M],[w]) has exactly the same result (i.e.
> >>>>>>>>>>>>>>>>> exactly the same behaviour)
> >>>>>>>>>>>>>>>>> as the direct computation M(w). This is actually the
> >>>>>>>>>>>>>>>>> definition of a UTM.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Another way of expressing this is: M(w) and
> >>>>>>>>>>>>>>>>> UTM([M],[w]) compute the same
> >>>>>>>>>>>>>>>>> partial function.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> You have made it abundantly clear that when you say
> >>>>>>>>>>>>>>>>> "the actual behavior
> >>>>>>>>>>>>>>>>> specified by this machine description", you do *not*
> >>>>>>>>>>>>>>>>> mean "the actual
> >>>>>>>>>>>>>>>>> behavior specified by this machine description",
> >>>>>>>>>>>>>>>>> because that's simply
> >>>>>>>>>>>>>>>>> the behaviour of M(w). What you *do* mean is "the
> >>>>>>>>>>>>>>>>> behaviour of your
> >>>>>>>>>>>>>>>>> particular, broken and incomplete, quasi-simulation
> >>>>>>>>>>>>>>>>> based on [M] and [w]".
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Why is it broken? Because it *doesn't* have the same
> >>>>>>>>>>>>>>>>> behaviour as M
> >>>>>>>>>>>>>>>>> (w),
> >>>>>>>>>>>>>>>>> nor as UTM([M],[w]). A correct simulation *means*
> >>>>>>>>>>>>>>>>> that it has the same
> >>>>>>>>>>>>>>>>> behaviour as M(w).
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Why is it incomplete? Because it aborts its
> >>>>>>>>>>>>>>>>> "simulation" before it reaches
> >>>>>>>>>>>>>>>>> a halting configuration of the machine represented
> >>>>>>>>>>>>>>>>> by its input, and it
> >>>>>>>>>>>>>>>>> does so on invalidly.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Why is it a quasi-simulation? Because it depends on
> >>>>>>>>>>>>>>>>> external input that is
> >>>>>>>>>>>>>>>>> contained in neither [M] nor [w]. You have said, on
> >>>>>>>>>>>>>>>>> numerous occasions,
> >>>>>>>>>>>>>>>>> that the behaviour of your "H(P,P)" depends on the
> >>>>>>>>>>>>>>>>> specific memory location of "P". Well, then that
> >>>>>>>>>>>>>>>>> location is an external input. Your H is
> >>>>>>>>>>>>>>>>> *not* analogous to Linz' H([M],[w]).
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> This is the point where you usually barf up your
> >>>>>>>>>>>>>>>>> stanza about how the
> >>>>>>>>>>>>>>>>> behaviour of your "H(P,P)" cannot be expected to be
> >>>>>>>>>>>>>>>>> computed "from the
> >>>>>>>>>>>>>>>>> non-input P(P)". This is obviously idiotic, for the
> >>>>>>>>>>>>>>>>> following reasons:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> 1) A purported halt decider H([M],[w]) is *not*
> >>>>>>>>>>>>>>>>> required to compute
> >>>>>>>>>>>>>>>>> its
> >>>>>>>>>>>>>>>>>     result *from* M(w), but to *match* M(w).
> >>>>>>>>>>>>>>>>> Computing *from* M(w) would be
> >>>>>>>>>>>>>>>>>     completely pointless, because the decider
> >>>>>>>>>>>>>>>>> would already know the
> >>>>>>>>>>>>>>>>> answer.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>     Since you seem unable to understand anything
> >>>>>>>>>>>>>>>>> but arguments from
> >>>>>>>>>>>>>>>>>     analogy, let me re-use one that you yourself
> >>>>>>>>>>>>>>>>> have employed: Suppose
> >>>>>>>>>>>>>>>>>     we want to construct an addition algorithm
> >>>>>>>>>>>>>>>>> add(x,y). If you were
> >>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>     complain that add(5,7) cannot be required to
> >>>>>>>>>>>>>>>>> compute its result
> >>>>>>>>>>>>>>>>> "from
> >>>>>>>>>>>>>>>>>     the non-input 12", you would, quite
> >>>>>>>>>>>>>>>>> rightly, be regarded as a complete
> >>>>>>>>>>>>>>>>>     nitwit. Can you now guess why you're
> >>>>>>>>>>>>>>>>> universally regarded as a complete
> >>>>>>>>>>>>>>>>>     nitwit?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> 2) The behaviour of UTM([M],[w]) is *defined* to
> >>>>>>>>>>>>>>>>> match the behaviour of M(w),
> >>>>>>>>>>>>>>>>>     and UTMs very evidently do exist. The
> >>>>>>>>>>>>>>>>> information contained in [M] and [w]
> >>>>>>>>>>>>>>>>>     is obviously enough to match the behaviour
> >>>>>>>>>>>>>>>>> of M(w). The fact that your
> >>>>>>>>>>>>>>>>>     "simulator" fails in this regard, is proof
> >>>>>>>>>>>>>>>>> that your "simulator" is
> >>>>>>>>>>>>>>>>>     defective -- *not* that you have discovered
> >>>>>>>>>>>>>>>>> a "loop hole", or that halting
> >>>>>>>>>>>>>>>>>     theorem is faulty, or anything of that kind
> >>>>>>>>>>>>>>>>> -- only that you're
> >>>>>>>>>>>>>>>>> working
> >>>>>>>>>>>>>>>>>     with a broken simulator.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> *NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE
> >>>>>>>>>>>>>>>>>> THERE IS NO ERROR*
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> A lot of people have pointed out many kinds of
> >>>>>>>>>>>>>>>>> errors in your reasoning.
> >>>>>>>>>>>>>>>>> You usually respond with some form "proof by
> >>>>>>>>>>>>>>>>> regurgitation". I expect you
> >>>>>>>>>>>>>>>>> will do so to this post.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> When-so-ever a simulating halt decider (SHD)
> >>>>>>>>>>>>>>>>>> correctly performs a partial simulation of its
> >>>>>>>>>>>>>>>>>> input and the behavior of this partial simulation
> >>>>>>>>>>>>>>>>>> correctly matches a non-halting behavior pattern
> >>>>>>>>>>>>>>>>>> then the SHD halt decider can correctly report
> >>>>>>>>>>>>>>>>>> non-halting.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> A non-halting behavior pattern is correct
> >>>>>>>>>>>>>>>>>> when-so-ever matching this
> >>>>>>>>>>>>>>>>>> behavior pattern proves that the correct and
> >>>>>>>>>>>>>>>>>> complete simulation of the
> >>>>>>>>>>>>>>>>>> input by SHD would never reach the final state of
> >>>>>>>>>>>>>>>>>> this simulated input.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Yeah, that's just a bunch of equivocations on
> >>>>>>>>>>>>>>>>> "correctly", "its input",
> >>>>>>>>>>>>>>>>> "non-halting behavior", and more.  Please learn to
> >>>>>>>>>>>>>>>>> write clearly.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Also, could you *please* stop misreading Linz! He
> >>>>>>>>>>>>>>>>> *doesn't* say that a TM
> >>>>>>>>>>>>>>>>> halts, only if it enters a "final state". What he
> >>>>>>>>>>>>>>>>> actually says is:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>      "A Turing machine is said to halt whenever
> >>>>>>>>>>>>>>>>> it reaches a configuration
> >>>>>>>>>>>>>>>>>      for which delta is not defined; this is
> >>>>>>>>>>>>>>>>> possible because delta
> >>>>>>>>>>>>>>>>> is a
> >>>>>>>>>>>>>>>>>      partial function. In fact, we will assume
> >>>>>>>>>>>>>>>>> that no transitions are
> >>>>>>>>>>>>>>>>>      defined for any final state, so the Turing
> >>>>>>>>>>>>>>>>> machine will halt whenever
> >>>>>>>>>>>>>>>>>      it enters a final state."
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> So, for a general TM, there may well be
> >>>>>>>>>>>>>>>>> configurations for which the TM
> >>>>>>>>>>>>>>>>> halts in a non-final state. It is, on the other
> >>>>>>>>>>>>>>>>> hand, understood that a TM
> >>>>>>>>>>>>>>>>> *only* stops running if enters a configuration for
> >>>>>>>>>>>>>>>>> which the transition
> >>>>>>>>>>>>>>>>> function is undefined.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> "Final states" only concern the *interpretation* of
> >>>>>>>>>>>>>>>>> the value of a computation -- *not* whether the TM
> >>>>>>>>>>>>>>>>> halts or not.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> This means that "halting" and "stops running" are
> >>>>>>>>>>>>>>>>> the exact the same things.
> >>>>>>>>>>>>>>>>> And obviously, "running" and "being simulated" are
> >>>>>>>>>>>>>>>>> two entirely different
> >>>>>>>>>>>>>>>>> things.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>    int Halt_Status = UTM(x, x);
> >>>>>>>>>>>>>>>>    if (Halt_Status)
> >>>>>>>>>>>>>>>>      HERE: goto HERE;
> >>>>>>>>>>>>>>>>    return;
> >>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> The behavior of the actual input to the simulating
> >>>>>>>>>>>>>>>> halt decider is the behavior of the above. Since C
> >>>>>>>>>>>>>>>> functions do not actually have UTM's a more accurate
> >>>>>>>>>>>>>>>> way of sayoing this is:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>    int Halt_Status = Simulate(x, x);
> >>>>>>>>>>>>>>>>    if (Halt_Status)
> >>>>>>>>>>>>>>>>      HERE: goto HERE;
> >>>>>>>>>>>>>>>>    return;
> >>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> The behavior of UTM(P,P) or Simulate(P,P) is not the
> >>>>>>>>>>>>>>>> behavior of the actual input to H(P,P) because it is
> >>>>>>>>>>>>>>>> at a different point in the execution trace than
> >>>>>>>>>>>>>>>> H(P,P).
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Wrong, at least if H is supposed to be a Halt Decider.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> You forget the question that the Halt Decider is being
> >>>>>>>>>>>>>>> asked to solve, which is what the machine represented
> >>>>>>>>>>>>>>> by its input would do.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> It is common knowledge that the correct and complete
> >>>>>>>>>>>>>> simulation of a machine description always provides the
> >>>>>>>>>>>>>> actual behavior specified by this machine description.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Right.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> That you (and others such as Ben) reject that the
> >>>>>>>>>>>>>> correct and complete simulation by H(P,P) of its input
> >>>>>>>>>>>>>> does provide the actual behavior of this input also
> >>>>>>>>>>>>>> rejects the notion of a UTM which you accept, thus you
> >>>>>>>>>>>>>> (and all others holding this view such as Ben)
> >>>>>>>>>>>>>> contradict yourself (themselves).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> So, why do you reject the actual correct and complete
> >>>>>>>>>>>>> simulation of the input to H when done by an actual pure
> >>>>>>>>>>>>> simulator/UTM?
> >>>>>>>>>>>> As long as it is done at the exact point in the execution
> >>>>>>>>>>>> trace as H(P,P) then it is fine, otherwise it is not the
> >>>>>>>>>>>> same as the simulation by H(P,P).
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> The simulation of the input to H(P,P) is the simulation of
> >>>>>>>>>>> the instruction sequence specified by the code of P (and
> >>>>>>>>>>> the routines it calls) and has ZERO dependency on what
> >>>>>>>>>>> happened before that call
> >>>>>>>>>>
> >>>>>>>>>> main()
> >>>>>>>>>> {
> >>>>>>>>>>    P(P); // depends on the return value from H(P,P);
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> The input to H(P,P) that H correctly simulates cannot
> >>>>>>>>>> possibly depend on the return value from H because this
> >>>>>>>>>> return value is unreachable by P:
> >>>>>>>>>
> >>>>>>>>> But it NEEDS to. That fact that it can't get the needed
> >>>>>>>>> value because of the limitation of your algorithm, doesn't
> >>>>>>>>> mean it gets to ignore it.
> >>>>>>>>>
> >>>>>>>>> Not, Mr Flibble has shown a way that H CAN determine the
> >>>>>>>>> behavior of P based on the return value of H, even though H
> >>>>>>>>> can simulate the path through itself.
> >>>>>>>>>
> >>>>>>>>> (As I pointed out a long time ago too).
> >>>>>>>>
> >>>>>>>> Every function that is called in infinite recursion cannot
> >>>>>>>> possibly correctly return to its caller. People that believe
> >>>>>>>> that it can are as wrong as if they disagreed with
> >>>>>>>> arithmetic.
> >>>>>>>
> >>>>>>> Your thinking isn't joined up. The Flibble Signaling Halt
> >>>>>>> Decider (TM) is *not* infinitely recursive (as you have been
> >>>>>>> told many times) so of course it is quite valid for it to
> >>>>>>> return a value to its caller. The only thing that suffers
> >>>>>>> from infinite recursion is your broken mess.
> >>>>>>>>
> >>>>>>>> If computer science says that a function called in finite
> >>>>>>>> recursion must return to its caller then computer science is
> >>>>>>>> wrong, one might as well have said the cats must be dogs.
> >>>>>>>
> >>>>>>> I assume you meant "infinite recursion". A function that
> >>>>>>> returns a value to its caller is *by definition* not
> >>>>>>> infinitely recursive.
> >>>>>>>
> >>>>>>> The Flibble Signaling Halt Decider (TM) just works, your mess
> >>>>>>> does not.
> >>>>>>>
> >>>>>>> /Flibble
> >>>>>>>
> >>>>>>
> >>>>>> You claim to be a "computer scientist" yet do not even
> >>>>>> understand the concept of unreachable code:
> >>>>>>
> >>>>>> void P(ptr x)
> >>>>>> {
> >>>>>> int Halt_Status = H(x, x);
> >>>>>> if (Halt_Status)
> >>>>>> HERE: goto HERE;
> >>>>>> return;
> >>>>>> }
> >>>>>>
> >>>>>> int main()
> >>>>>> {
> >>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>> }
> >>>>>>
> >>>>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
> >>>>>> (b) that simulates P(P) that calls a simulated H(P,P)
> >>>>>> (c) that simulates P(P) that calls a simulated H(P,P)
> >>>>>> (d) that simulates P(P) that calls a simulated H(P,P)...
> >>>>>> *Until H aborts its simulation*
> >>>>>
> >>>>> Virtually every reply you make now totally ignores what you are
> >>>>> replying to and instead is just regurgitation of the the same
> >>>>> old shit.
> >>>>>
> >>>>> I have shown on several occasions in replies to you that I fully
> >>>>> understand the concept of unreachable code.
> >>>>>
> >>>>> Again: the Flibble Signaling Halt Decider (TM) is *NOT*
> >>>>> recursive so your traces don't apply to it, your traces only
> >>>>> apply to your broken mess which has to "abort" the infinite
> >>>>> recursion which is YOUR design mistake.
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>
> >>>> Although H(P,P) does recognize and abort the simulation of its
> >>>> input before the first recursive call is invoked, it remains an
> >>>> easily verified fact that P specifies infinitely recursive
> >>>> simulation to every simulating halt decider.
> >>>
> >>> Obviously not a verified fact given the Flibble Signaling Halt
> >>> Decider (TM) is an example of a simulating halt decider that is
> >>> *not* recursive ergo there is no recursive simulation: instead
> >>> there is a forking simulation that allows the decider to return a
> >>> value to its caller in each fork.
> >>>
> >>> /Flibble
> >>>
> >>>
> >>
> >> When H(P,P) simulates exactly what its input specifies:
> >> no more and no less then this behavior results:
> >> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
> >> (b) that simulates P(P) that calls a simulated H(P,P)
> >> (c) that simulates P(P) that calls a simulated H(P,P)
> >> (d) that simulates P(P) that calls a simulated H(P,P)...
> >> *Until H aborts its simulation*
> >>
> >> When H(P,P) simulates anything besides exactly what its input
> >> specifies then its simulation is incorrect.
> >
> > Nope, the definition of a halt decider does not specify that a
> > simulating halt decider must be recursive in nature.
> >
>
> The definition of correct simulation requires that the line-by-line
> execution trace derived from simulation exactly matches the behavior
> specified by the line-by-line source-code of the simulated input.
>
> Mine does that, your does not, thus mine is correct and yours is
> incorrect.

On 8/22/2022 1:11 PM, Mr Flibble wrote:
> On Mon, 22 Aug 2022 13:02:07 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 8/22/2022 12:53 PM, Mr Flibble wrote:
>>> On Mon, 22 Aug 2022 12:50:20 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 8/22/2022 12:43 PM, Mr Flibble wrote:
>>>>> On Mon, 22 Aug 2022 12:39:41 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 8/22/2022 12:15 PM, Mr Flibble wrote:
>>>>>>> On Mon, 22 Aug 2022 12:04:11 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> On 8/22/2022 11:21 AM, Mr Flibble wrote:
>>>>>>>>> On Mon, 22 Aug 2022 09:31:47 -0500
>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 8/21/2022 10:37 PM, Richard Damon wrote:
>>>>>>>>>>> On 8/21/22 11:27 PM, olcott wrote:
>>>>>>>>>>>> On 8/21/2022 10:14 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 8/21/22 9:37 PM, olcott wrote:
>>>>>>>>>>>>>> On 8/21/2022 8:04 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 8/21/22 8:45 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 8/21/2022 1:04 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 8/21/22 11:36 AM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 8/21/2022 10:16 AM, Shvili, the Kookologist
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> On Sat, 20 Aug 2022 16:01:31 -0500, in article
>>>>>>>>>>>>>>>>>>> <crudnRbncP4E1pz- nZ2dnZfqlJzNnZ2d@giganews.com>,
>>>>>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> [snip]
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> It is common knowledge that [...]
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Have you noticed that almost every time you use this
>>>>>>>>>>>>>>>>>>> phrase, you're
>>>>>>>>>>>>>>>>>>> wrong?
>>>>>>>>>>>>>>>>>>> So also this time.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> [...] the correct and complete simulation of a
>>>>>>>>>>>>>>>>>>>> machine description [...]
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Machine descriptions are never simulated -- they're
>>>>>>>>>>>>>>>>>>> just sequences of symbols.
>>>>>>>>>>>>>>>>>>> and don't have any defined behaviour. The machines
>>>>>>>>>>>>>>>>>>> they *represent*
>>>>>>>>>>>>>>>>>>> may be
>>>>>>>>>>>>>>>>>>> simulated.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> [...] always provides the actual behavior specified
>>>>>>>>>>>>>>>>>>>> by this machine description.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> This is almost, but not quite, correct (if you fix
>>>>>>>>>>>>>>>>>>> it according to the
>>>>>>>>>>>>>>>>>>> previous paragraph). It would have been completely
>>>>>>>>>>>>>>>>>>> correct, if it weren't
>>>>>>>>>>>>>>>>>>> for the fact that you're using an utterly bizarre
>>>>>>>>>>>>>>>>>>> meaning for the phrase
>>>>>>>>>>>>>>>>>>> "the actual behavior specified by this machine
>>>>>>>>>>>>>>>>>>> description".
>>>>>>>>>>>>>>>>>>>> That you and others reject this when it is applied
>>>>>>>>>>>>>>>>>>>> to my simulating halt
>>>>>>>>>>>>>>>>>>>> decider implicitly rejects the notion of a UTM.
>>>>>>>>>>>>>>>>>>>> Since you and others do
>>>>>>>>>>>>>>>>>>>> accept the notion of a UTM, I have just proven that
>>>>>>>>>>>>>>>>>>>> your reasoning is
>>>>>>>>>>>>>>>>>>>> incoherent and/or inconsistent.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Let M be a given machine, with machine description
>>>>>>>>>>>>>>>>>>> [M], and let w be
>>>>>>>>>>>>>>>>>>> a given input tape, with tape description [w]. Then
>>>>>>>>>>>>>>>>>>> the "simulation"
>>>>>>>>>>>>>>>>>>> UTM([M],[w]) has exactly the same result (i.e.
>>>>>>>>>>>>>>>>>>> exactly the same behaviour)
>>>>>>>>>>>>>>>>>>> as the direct computation M(w). This is actually the
>>>>>>>>>>>>>>>>>>> definition of a UTM.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Another way of expressing this is: M(w) and
>>>>>>>>>>>>>>>>>>> UTM([M],[w]) compute the same
>>>>>>>>>>>>>>>>>>> partial function.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> You have made it abundantly clear that when you say
>>>>>>>>>>>>>>>>>>> "the actual behavior
>>>>>>>>>>>>>>>>>>> specified by this machine description", you do *not*
>>>>>>>>>>>>>>>>>>> mean "the actual
>>>>>>>>>>>>>>>>>>> behavior specified by this machine description",
>>>>>>>>>>>>>>>>>>> because that's simply
>>>>>>>>>>>>>>>>>>> the behaviour of M(w). What you *do* mean is "the
>>>>>>>>>>>>>>>>>>> behaviour of your
>>>>>>>>>>>>>>>>>>> particular, broken and incomplete, quasi-simulation
>>>>>>>>>>>>>>>>>>> based on [M] and [w]".
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Why is it broken? Because it *doesn't* have the same
>>>>>>>>>>>>>>>>>>> behaviour as M
>>>>>>>>>>>>>>>>>>> (w),
>>>>>>>>>>>>>>>>>>> nor as UTM([M],[w]). A correct simulation *means*
>>>>>>>>>>>>>>>>>>> that it has the same
>>>>>>>>>>>>>>>>>>> behaviour as M(w).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Why is it incomplete? Because it aborts its
>>>>>>>>>>>>>>>>>>> "simulation" before it reaches
>>>>>>>>>>>>>>>>>>> a halting configuration of the machine represented
>>>>>>>>>>>>>>>>>>> by its input, and it
>>>>>>>>>>>>>>>>>>> does so on invalidly.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Why is it a quasi-simulation? Because it depends on
>>>>>>>>>>>>>>>>>>> external input that is
>>>>>>>>>>>>>>>>>>> contained in neither [M] nor [w]. You have said, on
>>>>>>>>>>>>>>>>>>> numerous occasions,
>>>>>>>>>>>>>>>>>>> that the behaviour of your "H(P,P)" depends on the
>>>>>>>>>>>>>>>>>>> specific memory location of "P". Well, then that
>>>>>>>>>>>>>>>>>>> location is an external input. Your H is
>>>>>>>>>>>>>>>>>>> *not* analogous to Linz' H([M],[w]).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> This is the point where you usually barf up your
>>>>>>>>>>>>>>>>>>> stanza about how the
>>>>>>>>>>>>>>>>>>> behaviour of your "H(P,P)" cannot be expected to be
>>>>>>>>>>>>>>>>>>> computed "from the
>>>>>>>>>>>>>>>>>>> non-input P(P)". This is obviously idiotic, for the
>>>>>>>>>>>>>>>>>>> following reasons:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 1) A purported halt decider H([M],[w]) is *not*
>>>>>>>>>>>>>>>>>>> required to compute
>>>>>>>>>>>>>>>>>>> its
>>>>>>>>>>>>>>>>>>>     result *from* M(w), but to *match* M(w).
>>>>>>>>>>>>>>>>>>> Computing *from* M(w) would be
>>>>>>>>>>>>>>>>>>>     completely pointless, because the decider
>>>>>>>>>>>>>>>>>>> would already know the
>>>>>>>>>>>>>>>>>>> answer.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>     Since you seem unable to understand anything
>>>>>>>>>>>>>>>>>>> but arguments from
>>>>>>>>>>>>>>>>>>>     analogy, let me re-use one that you yourself
>>>>>>>>>>>>>>>>>>> have employed: Suppose
>>>>>>>>>>>>>>>>>>>     we want to construct an addition algorithm
>>>>>>>>>>>>>>>>>>> add(x,y). If you were
>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>     complain that add(5,7) cannot be required to
>>>>>>>>>>>>>>>>>>> compute its result
>>>>>>>>>>>>>>>>>>> "from
>>>>>>>>>>>>>>>>>>>     the non-input 12", you would, quite
>>>>>>>>>>>>>>>>>>> rightly, be regarded as a complete
>>>>>>>>>>>>>>>>>>>     nitwit. Can you now guess why you're
>>>>>>>>>>>>>>>>>>> universally regarded as a complete
>>>>>>>>>>>>>>>>>>>     nitwit?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2) The behaviour of UTM([M],[w]) is *defined* to
>>>>>>>>>>>>>>>>>>> match the behaviour of M(w),
>>>>>>>>>>>>>>>>>>>     and UTMs very evidently do exist. The
>>>>>>>>>>>>>>>>>>> information contained in [M] and [w]
>>>>>>>>>>>>>>>>>>>     is obviously enough to match the behaviour
>>>>>>>>>>>>>>>>>>> of M(w). The fact that your
>>>>>>>>>>>>>>>>>>>     "simulator" fails in this regard, is proof
>>>>>>>>>>>>>>>>>>> that your "simulator" is
>>>>>>>>>>>>>>>>>>>     defective -- *not* that you have discovered
>>>>>>>>>>>>>>>>>>> a "loop hole", or that halting
>>>>>>>>>>>>>>>>>>>     theorem is faulty, or anything of that kind
>>>>>>>>>>>>>>>>>>> -- only that you're
>>>>>>>>>>>>>>>>>>> working
>>>>>>>>>>>>>>>>>>>     with a broken simulator.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> *NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE
>>>>>>>>>>>>>>>>>>>> THERE IS NO ERROR*
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> A lot of people have pointed out many kinds of
>>>>>>>>>>>>>>>>>>> errors in your reasoning.
>>>>>>>>>>>>>>>>>>> You usually respond with some form "proof by
>>>>>>>>>>>>>>>>>>> regurgitation". I expect you
>>>>>>>>>>>>>>>>>>> will do so to this post.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> When-so-ever a simulating halt decider (SHD)
>>>>>>>>>>>>>>>>>>>> correctly performs a partial simulation of its
>>>>>>>>>>>>>>>>>>>> input and the behavior of this partial simulation
>>>>>>>>>>>>>>>>>>>> correctly matches a non-halting behavior pattern
>>>>>>>>>>>>>>>>>>>> then the SHD halt decider can correctly report
>>>>>>>>>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> A non-halting behavior pattern is correct
>>>>>>>>>>>>>>>>>>>> when-so-ever matching this
>>>>>>>>>>>>>>>>>>>> behavior pattern proves that the correct and
>>>>>>>>>>>>>>>>>>>> complete simulation of the
>>>>>>>>>>>>>>>>>>>> input by SHD would never reach the final state of
>>>>>>>>>>>>>>>>>>>> this simulated input.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Yeah, that's just a bunch of equivocations on
>>>>>>>>>>>>>>>>>>> "correctly", "its input",
>>>>>>>>>>>>>>>>>>> "non-halting behavior", and more.  Please learn to
>>>>>>>>>>>>>>>>>>> write clearly.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Also, could you *please* stop misreading Linz! He
>>>>>>>>>>>>>>>>>>> *doesn't* say that a TM
>>>>>>>>>>>>>>>>>>> halts, only if it enters a "final state". What he
>>>>>>>>>>>>>>>>>>> actually says is:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>      "A Turing machine is said to halt whenever
>>>>>>>>>>>>>>>>>>> it reaches a configuration
>>>>>>>>>>>>>>>>>>>      for which delta is not defined; this is
>>>>>>>>>>>>>>>>>>> possible because delta
>>>>>>>>>>>>>>>>>>> is a
>>>>>>>>>>>>>>>>>>>      partial function. In fact, we will assume
>>>>>>>>>>>>>>>>>>> that no transitions are
>>>>>>>>>>>>>>>>>>>      defined for any final state, so the Turing
>>>>>>>>>>>>>>>>>>> machine will halt whenever
>>>>>>>>>>>>>>>>>>>      it enters a final state."
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> So, for a general TM, there may well be
>>>>>>>>>>>>>>>>>>> configurations for which the TM
>>>>>>>>>>>>>>>>>>> halts in a non-final state. It is, on the other
>>>>>>>>>>>>>>>>>>> hand, understood that a TM
>>>>>>>>>>>>>>>>>>> *only* stops running if enters a configuration for
>>>>>>>>>>>>>>>>>>> which the transition
>>>>>>>>>>>>>>>>>>> function is undefined.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> "Final states" only concern the *interpretation* of
>>>>>>>>>>>>>>>>>>> the value of a computation -- *not* whether the TM
>>>>>>>>>>>>>>>>>>> halts or not.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> This means that "halting" and "stops running" are
>>>>>>>>>>>>>>>>>>> the exact the same things.
>>>>>>>>>>>>>>>>>>> And obviously, "running" and "being simulated" are
>>>>>>>>>>>>>>>>>>> two entirely different
>>>>>>>>>>>>>>>>>>> things.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>    int Halt_Status = UTM(x, x);
>>>>>>>>>>>>>>>>>>    if (Halt_Status)
>>>>>>>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>>>>>>>>    return;
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The behavior of the actual input to the simulating
>>>>>>>>>>>>>>>>>> halt decider is the behavior of the above. Since C
>>>>>>>>>>>>>>>>>> functions do not actually have UTM's a more accurate
>>>>>>>>>>>>>>>>>> way of sayoing this is:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>    int Halt_Status = Simulate(x, x);
>>>>>>>>>>>>>>>>>>    if (Halt_Status)
>>>>>>>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>>>>>>>>    return;
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The behavior of UTM(P,P) or Simulate(P,P) is not the
>>>>>>>>>>>>>>>>>> behavior of the actual input to H(P,P) because it is
>>>>>>>>>>>>>>>>>> at a different point in the execution trace than
>>>>>>>>>>>>>>>>>> H(P,P).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Wrong, at least if H is supposed to be a Halt Decider.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You forget the question that the Halt Decider is being
>>>>>>>>>>>>>>>>> asked to solve, which is what the machine represented
>>>>>>>>>>>>>>>>> by its input would do.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It is common knowledge that the correct and complete
>>>>>>>>>>>>>>>> simulation of a machine description always provides the
>>>>>>>>>>>>>>>> actual behavior specified by this machine description.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Right.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That you (and others such as Ben) reject that the
>>>>>>>>>>>>>>>> correct and complete simulation by H(P,P) of its input
>>>>>>>>>>>>>>>> does provide the actual behavior of this input also
>>>>>>>>>>>>>>>> rejects the notion of a UTM which you accept, thus you
>>>>>>>>>>>>>>>> (and all others holding this view such as Ben)
>>>>>>>>>>>>>>>> contradict yourself (themselves).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So, why do you reject the actual correct and complete
>>>>>>>>>>>>>>> simulation of the input to H when done by an actual pure
>>>>>>>>>>>>>>> simulator/UTM?
>>>>>>>>>>>>>> As long as it is done at the exact point in the execution
>>>>>>>>>>>>>> trace as H(P,P) then it is fine, otherwise it is not the
>>>>>>>>>>>>>> same as the simulation by H(P,P).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The simulation of the input to H(P,P) is the simulation of
>>>>>>>>>>>>> the instruction sequence specified by the code of P (and
>>>>>>>>>>>>> the routines it calls) and has ZERO dependency on what
>>>>>>>>>>>>> happened before that call
>>>>>>>>>>>>
>>>>>>>>>>>> main()
>>>>>>>>>>>> {
>>>>>>>>>>>>    P(P); // depends on the return value from H(P,P);
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> The input to H(P,P) that H correctly simulates cannot
>>>>>>>>>>>> possibly depend on the return value from H because this
>>>>>>>>>>>> return value is unreachable by P:
>>>>>>>>>>>
>>>>>>>>>>> But it NEEDS to. That fact that it can't get the needed
>>>>>>>>>>> value because of the limitation of your algorithm, doesn't
>>>>>>>>>>> mean it gets to ignore it.
>>>>>>>>>>>
>>>>>>>>>>> Not, Mr Flibble has shown a way that H CAN determine the
>>>>>>>>>>> behavior of P based on the return value of H, even though H
>>>>>>>>>>> can simulate the path through itself.
>>>>>>>>>>>
>>>>>>>>>>> (As I pointed out a long time ago too).
>>>>>>>>>>
>>>>>>>>>> Every function that is called in infinite recursion cannot
>>>>>>>>>> possibly correctly return to its caller. People that believe
>>>>>>>>>> that it can are as wrong as if they disagreed with
>>>>>>>>>> arithmetic.
>>>>>>>>>
>>>>>>>>> Your thinking isn't joined up. The Flibble Signaling Halt
>>>>>>>>> Decider (TM) is *not* infinitely recursive (as you have been
>>>>>>>>> told many times) so of course it is quite valid for it to
>>>>>>>>> return a value to its caller. The only thing that suffers
>>>>>>>>> from infinite recursion is your broken mess.
>>>>>>>>>>
>>>>>>>>>> If computer science says that a function called in finite
>>>>>>>>>> recursion must return to its caller then computer science is
>>>>>>>>>> wrong, one might as well have said the cats must be dogs.
>>>>>>>>>
>>>>>>>>> I assume you meant "infinite recursion". A function that
>>>>>>>>> returns a value to its caller is *by definition* not
>>>>>>>>> infinitely recursive.
>>>>>>>>>
>>>>>>>>> The Flibble Signaling Halt Decider (TM) just works, your mess
>>>>>>>>> does not.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>
>>>>>>>> You claim to be a "computer scientist" yet do not even
>>>>>>>> understand the concept of unreachable code:
>>>>>>>>
>>>>>>>> void P(ptr x)
>>>>>>>> {
>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>> if (Halt_Status)
>>>>>>>> HERE: goto HERE;
>>>>>>>> return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>> }
>>>>>>>>
>>>>>>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>>>>>>>> (b) that simulates P(P) that calls a simulated H(P,P)
>>>>>>>> (c) that simulates P(P) that calls a simulated H(P,P)
>>>>>>>> (d) that simulates P(P) that calls a simulated H(P,P)...
>>>>>>>> *Until H aborts its simulation*
>>>>>>>
>>>>>>> Virtually every reply you make now totally ignores what you are
>>>>>>> replying to and instead is just regurgitation of the the same
>>>>>>> old shit.
>>>>>>>
>>>>>>> I have shown on several occasions in replies to you that I fully
>>>>>>> understand the concept of unreachable code.
>>>>>>>
>>>>>>> Again: the Flibble Signaling Halt Decider (TM) is *NOT*
>>>>>>> recursive so your traces don't apply to it, your traces only
>>>>>>> apply to your broken mess which has to "abort" the infinite
>>>>>>> recursion which is YOUR design mistake.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> Although H(P,P) does recognize and abort the simulation of its
>>>>>> input before the first recursive call is invoked, it remains an
>>>>>> easily verified fact that P specifies infinitely recursive
>>>>>> simulation to every simulating halt decider.
>>>>>
>>>>> Obviously not a verified fact given the Flibble Signaling Halt
>>>>> Decider (TM) is an example of a simulating halt decider that is
>>>>> *not* recursive ergo there is no recursive simulation: instead
>>>>> there is a forking simulation that allows the decider to return a
>>>>> value to its caller in each fork.
>>>>>
>>>>> /Flibble
>>>>>
>>>>>
>>>>
>>>> When H(P,P) simulates exactly what its input specifies:
>>>> no more and no less then this behavior results:
>>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>>>> (b) that simulates P(P) that calls a simulated H(P,P)
>>>> (c) that simulates P(P) that calls a simulated H(P,P)
>>>> (d) that simulates P(P) that calls a simulated H(P,P)...
>>>> *Until H aborts its simulation*
>>>>
>>>> When H(P,P) simulates anything besides exactly what its input
>>>> specifies then its simulation is incorrect.
>>>
>>> Nope, the definition of a halt decider does not specify that a
>>> simulating halt decider must be recursive in nature.
>>>
>>
>> The definition of correct simulation requires that the line-by-line
>> execution trace derived from simulation exactly matches the behavior
>> specified by the line-by-line source-code of the simulated input.
>>
>> Mine does that, your does not, thus mine is correct and yours is
>> incorrect.
>
> Mine does that, yours does not, thus mine is correct and yours
> is incorrect: if P(P) halts then H(P,P) must return a value of 1
> irregardless of whether it is a simulating halt decider or not.
>
> /Flibble
>

On Mon, 22 Aug 2022 13:37:11 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 8/22/2022 1:11 PM, Mr Flibble wrote:
> > On Mon, 22 Aug 2022 13:02:07 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 8/22/2022 12:53 PM, Mr Flibble wrote:
> >>> On Mon, 22 Aug 2022 12:50:20 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 8/22/2022 12:43 PM, Mr Flibble wrote:
> >>>>> On Mon, 22 Aug 2022 12:39:41 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> On 8/22/2022 12:15 PM, Mr Flibble wrote:
> >>>>>>> On Mon, 22 Aug 2022 12:04:11 -0500
> >>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>
> >>>>>>>> On 8/22/2022 11:21 AM, Mr Flibble wrote:
> >>>>>>>>> On Mon, 22 Aug 2022 09:31:47 -0500
> >>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> On 8/21/2022 10:37 PM, Richard Damon wrote:
> >>>>>>>>>>> On 8/21/22 11:27 PM, olcott wrote:
> >>>>>>>>>>>> On 8/21/2022 10:14 PM, Richard Damon wrote:
> >>>>>>>>>>>>> On 8/21/22 9:37 PM, olcott wrote:
> >>>>>>>>>>>>>> On 8/21/2022 8:04 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On 8/21/22 8:45 PM, olcott wrote:
> >>>>>>>>>>>>>>>> On 8/21/2022 1:04 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>> On 8/21/22 11:36 AM, olcott wrote:
> >>>>>>>>>>>>>>>>>> On 8/21/2022 10:16 AM, Shvili, the Kookologist
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>> On Sat, 20 Aug 2022 16:01:31 -0500, in article
> >>>>>>>>>>>>>>>>>>> <crudnRbncP4E1pz- nZ2dnZfqlJzNnZ2d@giganews.com>,
> >>>>>>>>>>>>>>>>>>> olcott wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> [snip]
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> It is common knowledge that [...]
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Have you noticed that almost every time you use
> >>>>>>>>>>>>>>>>>>> this phrase, you're
> >>>>>>>>>>>>>>>>>>> wrong?
> >>>>>>>>>>>>>>>>>>> So also this time.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> [...] the correct and complete simulation of a
> >>>>>>>>>>>>>>>>>>>> machine description [...]
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Machine descriptions are never simulated --
> >>>>>>>>>>>>>>>>>>> they're just sequences of symbols.
> >>>>>>>>>>>>>>>>>>> and don't have any defined behaviour. The machines
> >>>>>>>>>>>>>>>>>>> they *represent*
> >>>>>>>>>>>>>>>>>>> may be
> >>>>>>>>>>>>>>>>>>> simulated.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> [...] always provides the actual behavior
> >>>>>>>>>>>>>>>>>>>> specified by this machine description.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> This is almost, but not quite, correct (if you fix
> >>>>>>>>>>>>>>>>>>> it according to the
> >>>>>>>>>>>>>>>>>>> previous paragraph). It would have been completely
> >>>>>>>>>>>>>>>>>>> correct, if it weren't
> >>>>>>>>>>>>>>>>>>> for the fact that you're using an utterly bizarre
> >>>>>>>>>>>>>>>>>>> meaning for the phrase
> >>>>>>>>>>>>>>>>>>> "the actual behavior specified by this machine
> >>>>>>>>>>>>>>>>>>> description".
> >>>>>>>>>>>>>>>>>>>> That you and others reject this when it is
> >>>>>>>>>>>>>>>>>>>> applied to my simulating halt
> >>>>>>>>>>>>>>>>>>>> decider implicitly rejects the notion of a UTM.
> >>>>>>>>>>>>>>>>>>>> Since you and others do
> >>>>>>>>>>>>>>>>>>>> accept the notion of a UTM, I have just proven
> >>>>>>>>>>>>>>>>>>>> that your reasoning is
> >>>>>>>>>>>>>>>>>>>> incoherent and/or inconsistent.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Let M be a given machine, with machine description
> >>>>>>>>>>>>>>>>>>> [M], and let w be
> >>>>>>>>>>>>>>>>>>> a given input tape, with tape description [w].
> >>>>>>>>>>>>>>>>>>> Then the "simulation"
> >>>>>>>>>>>>>>>>>>> UTM([M],[w]) has exactly the same result (i.e.
> >>>>>>>>>>>>>>>>>>> exactly the same behaviour)
> >>>>>>>>>>>>>>>>>>> as the direct computation M(w). This is actually
> >>>>>>>>>>>>>>>>>>> the definition of a UTM.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Another way of expressing this is: M(w) and
> >>>>>>>>>>>>>>>>>>> UTM([M],[w]) compute the same
> >>>>>>>>>>>>>>>>>>> partial function.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> You have made it abundantly clear that when you
> >>>>>>>>>>>>>>>>>>> say "the actual behavior
> >>>>>>>>>>>>>>>>>>> specified by this machine description", you do
> >>>>>>>>>>>>>>>>>>> *not* mean "the actual
> >>>>>>>>>>>>>>>>>>> behavior specified by this machine description",
> >>>>>>>>>>>>>>>>>>> because that's simply
> >>>>>>>>>>>>>>>>>>> the behaviour of M(w). What you *do* mean is "the
> >>>>>>>>>>>>>>>>>>> behaviour of your
> >>>>>>>>>>>>>>>>>>> particular, broken and incomplete,
> >>>>>>>>>>>>>>>>>>> quasi-simulation based on [M] and [w]".
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Why is it broken? Because it *doesn't* have the
> >>>>>>>>>>>>>>>>>>> same behaviour as M
> >>>>>>>>>>>>>>>>>>> (w),
> >>>>>>>>>>>>>>>>>>> nor as UTM([M],[w]). A correct simulation *means*
> >>>>>>>>>>>>>>>>>>> that it has the same
> >>>>>>>>>>>>>>>>>>> behaviour as M(w).
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Why is it incomplete? Because it aborts its
> >>>>>>>>>>>>>>>>>>> "simulation" before it reaches
> >>>>>>>>>>>>>>>>>>> a halting configuration of the machine represented
> >>>>>>>>>>>>>>>>>>> by its input, and it
> >>>>>>>>>>>>>>>>>>> does so on invalidly.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Why is it a quasi-simulation? Because it depends
> >>>>>>>>>>>>>>>>>>> on external input that is
> >>>>>>>>>>>>>>>>>>> contained in neither [M] nor [w]. You have said,
> >>>>>>>>>>>>>>>>>>> on numerous occasions,
> >>>>>>>>>>>>>>>>>>> that the behaviour of your "H(P,P)" depends on the
> >>>>>>>>>>>>>>>>>>> specific memory location of "P". Well, then that
> >>>>>>>>>>>>>>>>>>> location is an external input. Your H is
> >>>>>>>>>>>>>>>>>>> *not* analogous to Linz' H([M],[w]).
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> This is the point where you usually barf up your
> >>>>>>>>>>>>>>>>>>> stanza about how the
> >>>>>>>>>>>>>>>>>>> behaviour of your "H(P,P)" cannot be expected to
> >>>>>>>>>>>>>>>>>>> be computed "from the
> >>>>>>>>>>>>>>>>>>> non-input P(P)". This is obviously idiotic, for
> >>>>>>>>>>>>>>>>>>> the following reasons:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> 1) A purported halt decider H([M],[w]) is *not*
> >>>>>>>>>>>>>>>>>>> required to compute
> >>>>>>>>>>>>>>>>>>> its
> >>>>>>>>>>>>>>>>>>>     result *from* M(w), but to *match* M(w).
> >>>>>>>>>>>>>>>>>>> Computing *from* M(w) would be
> >>>>>>>>>>>>>>>>>>>     completely pointless, because the decider
> >>>>>>>>>>>>>>>>>>> would already know the
> >>>>>>>>>>>>>>>>>>> answer.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>     Since you seem unable to understand
> >>>>>>>>>>>>>>>>>>> anything but arguments from
> >>>>>>>>>>>>>>>>>>>     analogy, let me re-use one that you
> >>>>>>>>>>>>>>>>>>> yourself have employed: Suppose
> >>>>>>>>>>>>>>>>>>>     we want to construct an addition
> >>>>>>>>>>>>>>>>>>> algorithm add(x,y). If you were
> >>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>     complain that add(5,7) cannot be
> >>>>>>>>>>>>>>>>>>> required to compute its result
> >>>>>>>>>>>>>>>>>>> "from
> >>>>>>>>>>>>>>>>>>>     the non-input 12", you would, quite
> >>>>>>>>>>>>>>>>>>> rightly, be regarded as a complete
> >>>>>>>>>>>>>>>>>>>     nitwit. Can you now guess why you're
> >>>>>>>>>>>>>>>>>>> universally regarded as a complete
> >>>>>>>>>>>>>>>>>>>     nitwit?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> 2) The behaviour of UTM([M],[w]) is *defined* to
> >>>>>>>>>>>>>>>>>>> match the behaviour of M(w),
> >>>>>>>>>>>>>>>>>>>     and UTMs very evidently do exist. The
> >>>>>>>>>>>>>>>>>>> information contained in [M] and [w]
> >>>>>>>>>>>>>>>>>>>     is obviously enough to match the
> >>>>>>>>>>>>>>>>>>> behaviour of M(w). The fact that your
> >>>>>>>>>>>>>>>>>>>     "simulator" fails in this regard, is
> >>>>>>>>>>>>>>>>>>> proof that your "simulator" is
> >>>>>>>>>>>>>>>>>>>     defective -- *not* that you have
> >>>>>>>>>>>>>>>>>>> discovered a "loop hole", or that halting
> >>>>>>>>>>>>>>>>>>>     theorem is faulty, or anything of that
> >>>>>>>>>>>>>>>>>>> kind -- only that you're
> >>>>>>>>>>>>>>>>>>> working
> >>>>>>>>>>>>>>>>>>>     with a broken simulator.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> *NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE
> >>>>>>>>>>>>>>>>>>>> THERE IS NO ERROR*
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> A lot of people have pointed out many kinds of
> >>>>>>>>>>>>>>>>>>> errors in your reasoning.
> >>>>>>>>>>>>>>>>>>> You usually respond with some form "proof by
> >>>>>>>>>>>>>>>>>>> regurgitation". I expect you
> >>>>>>>>>>>>>>>>>>> will do so to this post.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> When-so-ever a simulating halt decider (SHD)
> >>>>>>>>>>>>>>>>>>>> correctly performs a partial simulation of its
> >>>>>>>>>>>>>>>>>>>> input and the behavior of this partial simulation
> >>>>>>>>>>>>>>>>>>>> correctly matches a non-halting behavior pattern
> >>>>>>>>>>>>>>>>>>>> then the SHD halt decider can correctly report
> >>>>>>>>>>>>>>>>>>>> non-halting.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> A non-halting behavior pattern is correct
> >>>>>>>>>>>>>>>>>>>> when-so-ever matching this
> >>>>>>>>>>>>>>>>>>>> behavior pattern proves that the correct and
> >>>>>>>>>>>>>>>>>>>> complete simulation of the
> >>>>>>>>>>>>>>>>>>>> input by SHD would never reach the final state of
> >>>>>>>>>>>>>>>>>>>> this simulated input.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Yeah, that's just a bunch of equivocations on
> >>>>>>>>>>>>>>>>>>> "correctly", "its input",
> >>>>>>>>>>>>>>>>>>> "non-halting behavior", and more.  Please learn to
> >>>>>>>>>>>>>>>>>>> write clearly.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Also, could you *please* stop misreading Linz! He
> >>>>>>>>>>>>>>>>>>> *doesn't* say that a TM
> >>>>>>>>>>>>>>>>>>> halts, only if it enters a "final state". What he
> >>>>>>>>>>>>>>>>>>> actually says is:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>      "A Turing machine is said to halt
> >>>>>>>>>>>>>>>>>>> whenever it reaches a configuration
> >>>>>>>>>>>>>>>>>>>      for which delta is not defined; this is
> >>>>>>>>>>>>>>>>>>> possible because delta
> >>>>>>>>>>>>>>>>>>> is a
> >>>>>>>>>>>>>>>>>>>      partial function. In fact, we will
> >>>>>>>>>>>>>>>>>>> assume that no transitions are
> >>>>>>>>>>>>>>>>>>>      defined for any final state, so the
> >>>>>>>>>>>>>>>>>>> Turing machine will halt whenever
> >>>>>>>>>>>>>>>>>>>      it enters a final state."
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> So, for a general TM, there may well be
> >>>>>>>>>>>>>>>>>>> configurations for which the TM
> >>>>>>>>>>>>>>>>>>> halts in a non-final state. It is, on the other
> >>>>>>>>>>>>>>>>>>> hand, understood that a TM
> >>>>>>>>>>>>>>>>>>> *only* stops running if enters a configuration for
> >>>>>>>>>>>>>>>>>>> which the transition
> >>>>>>>>>>>>>>>>>>> function is undefined.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> "Final states" only concern the *interpretation*
> >>>>>>>>>>>>>>>>>>> of the value of a computation -- *not* whether
> >>>>>>>>>>>>>>>>>>> the TM halts or not.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> This means that "halting" and "stops running" are
> >>>>>>>>>>>>>>>>>>> the exact the same things.
> >>>>>>>>>>>>>>>>>>> And obviously, "running" and "being simulated" are
> >>>>>>>>>>>>>>>>>>> two entirely different
> >>>>>>>>>>>>>>>>>>> things.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>    int Halt_Status = UTM(x, x);
> >>>>>>>>>>>>>>>>>>    if (Halt_Status)
> >>>>>>>>>>>>>>>>>>      HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>    return;
> >>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> The behavior of the actual input to the simulating
> >>>>>>>>>>>>>>>>>> halt decider is the behavior of the above. Since C
> >>>>>>>>>>>>>>>>>> functions do not actually have UTM's a more
> >>>>>>>>>>>>>>>>>> accurate way of sayoing this is:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>    int Halt_Status = Simulate(x, x);
> >>>>>>>>>>>>>>>>>>    if (Halt_Status)
> >>>>>>>>>>>>>>>>>>      HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>    return;
> >>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> The behavior of UTM(P,P) or Simulate(P,P) is not
> >>>>>>>>>>>>>>>>>> the behavior of the actual input to H(P,P) because
> >>>>>>>>>>>>>>>>>> it is at a different point in the execution trace
> >>>>>>>>>>>>>>>>>> than H(P,P).
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Wrong, at least if H is supposed to be a Halt
> >>>>>>>>>>>>>>>>> Decider.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> You forget the question that the Halt Decider is
> >>>>>>>>>>>>>>>>> being asked to solve, which is what the machine
> >>>>>>>>>>>>>>>>> represented by its input would do.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> It is common knowledge that the correct and complete
> >>>>>>>>>>>>>>>> simulation of a machine description always provides
> >>>>>>>>>>>>>>>> the actual behavior specified by this machine
> >>>>>>>>>>>>>>>> description.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Right.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> That you (and others such as Ben) reject that the
> >>>>>>>>>>>>>>>> correct and complete simulation by H(P,P) of its
> >>>>>>>>>>>>>>>> input does provide the actual behavior of this input
> >>>>>>>>>>>>>>>> also rejects the notion of a UTM which you accept,
> >>>>>>>>>>>>>>>> thus you (and all others holding this view such as
> >>>>>>>>>>>>>>>> Ben) contradict yourself (themselves).
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> So, why do you reject the actual correct and complete
> >>>>>>>>>>>>>>> simulation of the input to H when done by an actual
> >>>>>>>>>>>>>>> pure simulator/UTM?
> >>>>>>>>>>>>>> As long as it is done at the exact point in the
> >>>>>>>>>>>>>> execution trace as H(P,P) then it is fine, otherwise
> >>>>>>>>>>>>>> it is not the same as the simulation by H(P,P).
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> The simulation of the input to H(P,P) is the simulation
> >>>>>>>>>>>>> of the instruction sequence specified by the code of P
> >>>>>>>>>>>>> (and the routines it calls) and has ZERO dependency on
> >>>>>>>>>>>>> what happened before that call
> >>>>>>>>>>>>
> >>>>>>>>>>>> main()
> >>>>>>>>>>>> {
> >>>>>>>>>>>>    P(P); // depends on the return value from H(P,P);
> >>>>>>>>>>>> }
> >>>>>>>>>>>>
> >>>>>>>>>>>> The input to H(P,P) that H correctly simulates cannot
> >>>>>>>>>>>> possibly depend on the return value from H because this
> >>>>>>>>>>>> return value is unreachable by P:
> >>>>>>>>>>>
> >>>>>>>>>>> But it NEEDS to. That fact that it can't get the needed
> >>>>>>>>>>> value because of the limitation of your algorithm, doesn't
> >>>>>>>>>>> mean it gets to ignore it.
> >>>>>>>>>>>
> >>>>>>>>>>> Not, Mr Flibble has shown a way that H CAN determine the
> >>>>>>>>>>> behavior of P based on the return value of H, even though
> >>>>>>>>>>> H can simulate the path through itself.
> >>>>>>>>>>>
> >>>>>>>>>>> (As I pointed out a long time ago too).
> >>>>>>>>>>
> >>>>>>>>>> Every function that is called in infinite recursion cannot
> >>>>>>>>>> possibly correctly return to its caller. People that
> >>>>>>>>>> believe that it can are as wrong as if they disagreed with
> >>>>>>>>>> arithmetic.
> >>>>>>>>>
> >>>>>>>>> Your thinking isn't joined up. The Flibble Signaling Halt
> >>>>>>>>> Decider (TM) is *not* infinitely recursive (as you have been
> >>>>>>>>> told many times) so of course it is quite valid for it to
> >>>>>>>>> return a value to its caller. The only thing that suffers
> >>>>>>>>> from infinite recursion is your broken mess.
> >>>>>>>>>>
> >>>>>>>>>> If computer science says that a function called in finite
> >>>>>>>>>> recursion must return to its caller then computer science
> >>>>>>>>>> is wrong, one might as well have said the cats must be
> >>>>>>>>>> dogs.
> >>>>>>>>>
> >>>>>>>>> I assume you meant "infinite recursion". A function that
> >>>>>>>>> returns a value to its caller is *by definition* not
> >>>>>>>>> infinitely recursive.
> >>>>>>>>>
> >>>>>>>>> The Flibble Signaling Halt Decider (TM) just works, your
> >>>>>>>>> mess does not.
> >>>>>>>>>
> >>>>>>>>> /Flibble
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> You claim to be a "computer scientist" yet do not even
> >>>>>>>> understand the concept of unreachable code:
> >>>>>>>>
> >>>>>>>> void P(ptr x)
> >>>>>>>> {
> >>>>>>>> int Halt_Status = H(x, x);
> >>>>>>>> if (Halt_Status)
> >>>>>>>> HERE: goto HERE;
> >>>>>>>> return;
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> int main()
> >>>>>>>> {
> >>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
> >>>>>>>> (b) that simulates P(P) that calls a simulated H(P,P)
> >>>>>>>> (c) that simulates P(P) that calls a simulated H(P,P)
> >>>>>>>> (d) that simulates P(P) that calls a simulated H(P,P)...
> >>>>>>>> *Until H aborts its simulation*
> >>>>>>>
> >>>>>>> Virtually every reply you make now totally ignores what you
> >>>>>>> are replying to and instead is just regurgitation of the the
> >>>>>>> same old shit.
> >>>>>>>
> >>>>>>> I have shown on several occasions in replies to you that I
> >>>>>>> fully understand the concept of unreachable code.
> >>>>>>>
> >>>>>>> Again: the Flibble Signaling Halt Decider (TM) is *NOT*
> >>>>>>> recursive so your traces don't apply to it, your traces only
> >>>>>>> apply to your broken mess which has to "abort" the infinite
> >>>>>>> recursion which is YOUR design mistake.
> >>>>>>>
> >>>>>>> /Flibble
> >>>>>>>
> >>>>>>
> >>>>>> Although H(P,P) does recognize and abort the simulation of its
> >>>>>> input before the first recursive call is invoked, it remains an
> >>>>>> easily verified fact that P specifies infinitely recursive
> >>>>>> simulation to every simulating halt decider.
> >>>>>
> >>>>> Obviously not a verified fact given the Flibble Signaling Halt
> >>>>> Decider (TM) is an example of a simulating halt decider that is
> >>>>> *not* recursive ergo there is no recursive simulation: instead
> >>>>> there is a forking simulation that allows the decider to return
> >>>>> a value to its caller in each fork.
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>>
> >>>>
> >>>> When H(P,P) simulates exactly what its input specifies:
> >>>> no more and no less then this behavior results:
> >>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
> >>>> (b) that simulates P(P) that calls a simulated H(P,P)
> >>>> (c) that simulates P(P) that calls a simulated H(P,P)
> >>>> (d) that simulates P(P) that calls a simulated H(P,P)...
> >>>> *Until H aborts its simulation*
> >>>>
> >>>> When H(P,P) simulates anything besides exactly what its input
> >>>> specifies then its simulation is incorrect.
> >>>
> >>> Nope, the definition of a halt decider does not specify that a
> >>> simulating halt decider must be recursive in nature.
> >>>
> >>
> >> The definition of correct simulation requires that the line-by-line
> >> execution trace derived from simulation exactly matches the
> >> behavior specified by the line-by-line source-code of the
> >> simulated input.
> >>
> >> Mine does that, your does not, thus mine is correct and yours is
> >> incorrect.
> >
> > Mine does that, yours does not, thus mine is correct and yours
> > is incorrect: if P(P) halts then H(P,P) must return a value of 1
> > irregardless of whether it is a simulating halt decider or not.
> >
> > /Flibble
> >
>
> So you disagree that a correct x86 emulation of the input to H(P,P)
> must show line-by-line that the execution trace of the simulated
> input exactly matches the x86 source-code of this input?
> (a) Yes you disagree
> (b) No you do not disagree.
>
> Ant answer not having Yes or No will be considered a dishonest dodge.

On 8/22/2022 2:24 PM, Mr Flibble wrote:
> On Mon, 22 Aug 2022 13:37:11 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 8/22/2022 1:11 PM, Mr Flibble wrote:
>>> On Mon, 22 Aug 2022 13:02:07 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 8/22/2022 12:53 PM, Mr Flibble wrote:
>>>>> On Mon, 22 Aug 2022 12:50:20 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 8/22/2022 12:43 PM, Mr Flibble wrote:
>>>>>>> On Mon, 22 Aug 2022 12:39:41 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> On 8/22/2022 12:15 PM, Mr Flibble wrote:
>>>>>>>>> On Mon, 22 Aug 2022 12:04:11 -0500
>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 8/22/2022 11:21 AM, Mr Flibble wrote:
>>>>>>>>>>> On Mon, 22 Aug 2022 09:31:47 -0500
>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 8/21/2022 10:37 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 8/21/22 11:27 PM, olcott wrote:
>>>>>>>>>>>>>> On 8/21/2022 10:14 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 8/21/22 9:37 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 8/21/2022 8:04 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 8/21/22 8:45 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 8/21/2022 1:04 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 8/21/22 11:36 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 8/21/2022 10:16 AM, Shvili, the Kookologist
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>> On Sat, 20 Aug 2022 16:01:31 -0500, in article
>>>>>>>>>>>>>>>>>>>>> <crudnRbncP4E1pz- nZ2dnZfqlJzNnZ2d@giganews.com>,
>>>>>>>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> [snip]
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> It is common knowledge that [...]
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Have you noticed that almost every time you use
>>>>>>>>>>>>>>>>>>>>> this phrase, you're
>>>>>>>>>>>>>>>>>>>>> wrong?
>>>>>>>>>>>>>>>>>>>>> So also this time.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> [...] the correct and complete simulation of a
>>>>>>>>>>>>>>>>>>>>>> machine description [...]
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Machine descriptions are never simulated --
>>>>>>>>>>>>>>>>>>>>> they're just sequences of symbols.
>>>>>>>>>>>>>>>>>>>>> and don't have any defined behaviour. The machines
>>>>>>>>>>>>>>>>>>>>> they *represent*
>>>>>>>>>>>>>>>>>>>>> may be
>>>>>>>>>>>>>>>>>>>>> simulated.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> [...] always provides the actual behavior
>>>>>>>>>>>>>>>>>>>>>> specified by this machine description.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> This is almost, but not quite, correct (if you fix
>>>>>>>>>>>>>>>>>>>>> it according to the
>>>>>>>>>>>>>>>>>>>>> previous paragraph). It would have been completely
>>>>>>>>>>>>>>>>>>>>> correct, if it weren't
>>>>>>>>>>>>>>>>>>>>> for the fact that you're using an utterly bizarre
>>>>>>>>>>>>>>>>>>>>> meaning for the phrase
>>>>>>>>>>>>>>>>>>>>> "the actual behavior specified by this machine
>>>>>>>>>>>>>>>>>>>>> description".
>>>>>>>>>>>>>>>>>>>>>> That you and others reject this when it is
>>>>>>>>>>>>>>>>>>>>>> applied to my simulating halt
>>>>>>>>>>>>>>>>>>>>>> decider implicitly rejects the notion of a UTM.
>>>>>>>>>>>>>>>>>>>>>> Since you and others do
>>>>>>>>>>>>>>>>>>>>>> accept the notion of a UTM, I have just proven
>>>>>>>>>>>>>>>>>>>>>> that your reasoning is
>>>>>>>>>>>>>>>>>>>>>> incoherent and/or inconsistent.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Let M be a given machine, with machine description
>>>>>>>>>>>>>>>>>>>>> [M], and let w be
>>>>>>>>>>>>>>>>>>>>> a given input tape, with tape description [w].
>>>>>>>>>>>>>>>>>>>>> Then the "simulation"
>>>>>>>>>>>>>>>>>>>>> UTM([M],[w]) has exactly the same result (i.e.
>>>>>>>>>>>>>>>>>>>>> exactly the same behaviour)
>>>>>>>>>>>>>>>>>>>>> as the direct computation M(w). This is actually
>>>>>>>>>>>>>>>>>>>>> the definition of a UTM.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Another way of expressing this is: M(w) and
>>>>>>>>>>>>>>>>>>>>> UTM([M],[w]) compute the same
>>>>>>>>>>>>>>>>>>>>> partial function.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> You have made it abundantly clear that when you
>>>>>>>>>>>>>>>>>>>>> say "the actual behavior
>>>>>>>>>>>>>>>>>>>>> specified by this machine description", you do
>>>>>>>>>>>>>>>>>>>>> *not* mean "the actual
>>>>>>>>>>>>>>>>>>>>> behavior specified by this machine description",
>>>>>>>>>>>>>>>>>>>>> because that's simply
>>>>>>>>>>>>>>>>>>>>> the behaviour of M(w). What you *do* mean is "the
>>>>>>>>>>>>>>>>>>>>> behaviour of your
>>>>>>>>>>>>>>>>>>>>> particular, broken and incomplete,
>>>>>>>>>>>>>>>>>>>>> quasi-simulation based on [M] and [w]".
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Why is it broken? Because it *doesn't* have the
>>>>>>>>>>>>>>>>>>>>> same behaviour as M
>>>>>>>>>>>>>>>>>>>>> (w),
>>>>>>>>>>>>>>>>>>>>> nor as UTM([M],[w]). A correct simulation *means*
>>>>>>>>>>>>>>>>>>>>> that it has the same
>>>>>>>>>>>>>>>>>>>>> behaviour as M(w).
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Why is it incomplete? Because it aborts its
>>>>>>>>>>>>>>>>>>>>> "simulation" before it reaches
>>>>>>>>>>>>>>>>>>>>> a halting configuration of the machine represented
>>>>>>>>>>>>>>>>>>>>> by its input, and it
>>>>>>>>>>>>>>>>>>>>> does so on invalidly.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Why is it a quasi-simulation? Because it depends
>>>>>>>>>>>>>>>>>>>>> on external input that is
>>>>>>>>>>>>>>>>>>>>> contained in neither [M] nor [w]. You have said,
>>>>>>>>>>>>>>>>>>>>> on numerous occasions,
>>>>>>>>>>>>>>>>>>>>> that the behaviour of your "H(P,P)" depends on the
>>>>>>>>>>>>>>>>>>>>> specific memory location of "P". Well, then that
>>>>>>>>>>>>>>>>>>>>> location is an external input. Your H is
>>>>>>>>>>>>>>>>>>>>> *not* analogous to Linz' H([M],[w]).
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> This is the point where you usually barf up your
>>>>>>>>>>>>>>>>>>>>> stanza about how the
>>>>>>>>>>>>>>>>>>>>> behaviour of your "H(P,P)" cannot be expected to
>>>>>>>>>>>>>>>>>>>>> be computed "from the
>>>>>>>>>>>>>>>>>>>>> non-input P(P)". This is obviously idiotic, for
>>>>>>>>>>>>>>>>>>>>> the following reasons:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 1) A purported halt decider H([M],[w]) is *not*
>>>>>>>>>>>>>>>>>>>>> required to compute
>>>>>>>>>>>>>>>>>>>>> its
>>>>>>>>>>>>>>>>>>>>>     result *from* M(w), but to *match* M(w).
>>>>>>>>>>>>>>>>>>>>> Computing *from* M(w) would be
>>>>>>>>>>>>>>>>>>>>>     completely pointless, because the decider
>>>>>>>>>>>>>>>>>>>>> would already know the
>>>>>>>>>>>>>>>>>>>>> answer.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>     Since you seem unable to understand
>>>>>>>>>>>>>>>>>>>>> anything but arguments from
>>>>>>>>>>>>>>>>>>>>>     analogy, let me re-use one that you
>>>>>>>>>>>>>>>>>>>>> yourself have employed: Suppose
>>>>>>>>>>>>>>>>>>>>>     we want to construct an addition
>>>>>>>>>>>>>>>>>>>>> algorithm add(x,y). If you were
>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>     complain that add(5,7) cannot be
>>>>>>>>>>>>>>>>>>>>> required to compute its result
>>>>>>>>>>>>>>>>>>>>> "from
>>>>>>>>>>>>>>>>>>>>>     the non-input 12", you would, quite
>>>>>>>>>>>>>>>>>>>>> rightly, be regarded as a complete
>>>>>>>>>>>>>>>>>>>>>     nitwit. Can you now guess why you're
>>>>>>>>>>>>>>>>>>>>> universally regarded as a complete
>>>>>>>>>>>>>>>>>>>>>     nitwit?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 2) The behaviour of UTM([M],[w]) is *defined* to
>>>>>>>>>>>>>>>>>>>>> match the behaviour of M(w),
>>>>>>>>>>>>>>>>>>>>>     and UTMs very evidently do exist. The
>>>>>>>>>>>>>>>>>>>>> information contained in [M] and [w]
>>>>>>>>>>>>>>>>>>>>>     is obviously enough to match the
>>>>>>>>>>>>>>>>>>>>> behaviour of M(w). The fact that your
>>>>>>>>>>>>>>>>>>>>>     "simulator" fails in this regard, is
>>>>>>>>>>>>>>>>>>>>> proof that your "simulator" is
>>>>>>>>>>>>>>>>>>>>>     defective -- *not* that you have
>>>>>>>>>>>>>>>>>>>>> discovered a "loop hole", or that halting
>>>>>>>>>>>>>>>>>>>>>     theorem is faulty, or anything of that
>>>>>>>>>>>>>>>>>>>>> kind -- only that you're
>>>>>>>>>>>>>>>>>>>>> working
>>>>>>>>>>>>>>>>>>>>>     with a broken simulator.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> *NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE
>>>>>>>>>>>>>>>>>>>>>> THERE IS NO ERROR*
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> A lot of people have pointed out many kinds of
>>>>>>>>>>>>>>>>>>>>> errors in your reasoning.
>>>>>>>>>>>>>>>>>>>>> You usually respond with some form "proof by
>>>>>>>>>>>>>>>>>>>>> regurgitation". I expect you
>>>>>>>>>>>>>>>>>>>>> will do so to this post.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> When-so-ever a simulating halt decider (SHD)
>>>>>>>>>>>>>>>>>>>>>> correctly performs a partial simulation of its
>>>>>>>>>>>>>>>>>>>>>> input and the behavior of this partial simulation
>>>>>>>>>>>>>>>>>>>>>> correctly matches a non-halting behavior pattern
>>>>>>>>>>>>>>>>>>>>>> then the SHD halt decider can correctly report
>>>>>>>>>>>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> A non-halting behavior pattern is correct
>>>>>>>>>>>>>>>>>>>>>> when-so-ever matching this
>>>>>>>>>>>>>>>>>>>>>> behavior pattern proves that the correct and
>>>>>>>>>>>>>>>>>>>>>> complete simulation of the
>>>>>>>>>>>>>>>>>>>>>> input by SHD would never reach the final state of
>>>>>>>>>>>>>>>>>>>>>> this simulated input.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Yeah, that's just a bunch of equivocations on
>>>>>>>>>>>>>>>>>>>>> "correctly", "its input",
>>>>>>>>>>>>>>>>>>>>> "non-halting behavior", and more.  Please learn to
>>>>>>>>>>>>>>>>>>>>> write clearly.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Also, could you *please* stop misreading Linz! He
>>>>>>>>>>>>>>>>>>>>> *doesn't* say that a TM
>>>>>>>>>>>>>>>>>>>>> halts, only if it enters a "final state". What he
>>>>>>>>>>>>>>>>>>>>> actually says is:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>      "A Turing machine is said to halt
>>>>>>>>>>>>>>>>>>>>> whenever it reaches a configuration
>>>>>>>>>>>>>>>>>>>>>      for which delta is not defined; this is
>>>>>>>>>>>>>>>>>>>>> possible because delta
>>>>>>>>>>>>>>>>>>>>> is a
>>>>>>>>>>>>>>>>>>>>>      partial function. In fact, we will
>>>>>>>>>>>>>>>>>>>>> assume that no transitions are
>>>>>>>>>>>>>>>>>>>>>      defined for any final state, so the
>>>>>>>>>>>>>>>>>>>>> Turing machine will halt whenever
>>>>>>>>>>>>>>>>>>>>>      it enters a final state."
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> So, for a general TM, there may well be
>>>>>>>>>>>>>>>>>>>>> configurations for which the TM
>>>>>>>>>>>>>>>>>>>>> halts in a non-final state. It is, on the other
>>>>>>>>>>>>>>>>>>>>> hand, understood that a TM
>>>>>>>>>>>>>>>>>>>>> *only* stops running if enters a configuration for
>>>>>>>>>>>>>>>>>>>>> which the transition
>>>>>>>>>>>>>>>>>>>>> function is undefined.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> "Final states" only concern the *interpretation*
>>>>>>>>>>>>>>>>>>>>> of the value of a computation -- *not* whether
>>>>>>>>>>>>>>>>>>>>> the TM halts or not.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> This means that "halting" and "stops running" are
>>>>>>>>>>>>>>>>>>>>> the exact the same things.
>>>>>>>>>>>>>>>>>>>>> And obviously, "running" and "being simulated" are
>>>>>>>>>>>>>>>>>>>>> two entirely different
>>>>>>>>>>>>>>>>>>>>> things.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>    int Halt_Status = UTM(x, x);
>>>>>>>>>>>>>>>>>>>>    if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>    return;
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The behavior of the actual input to the simulating
>>>>>>>>>>>>>>>>>>>> halt decider is the behavior of the above. Since C
>>>>>>>>>>>>>>>>>>>> functions do not actually have UTM's a more
>>>>>>>>>>>>>>>>>>>> accurate way of sayoing this is:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>    int Halt_Status = Simulate(x, x);
>>>>>>>>>>>>>>>>>>>>    if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>    return;
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The behavior of UTM(P,P) or Simulate(P,P) is not
>>>>>>>>>>>>>>>>>>>> the behavior of the actual input to H(P,P) because
>>>>>>>>>>>>>>>>>>>> it is at a different point in the execution trace
>>>>>>>>>>>>>>>>>>>> than H(P,P).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Wrong, at least if H is supposed to be a Halt
>>>>>>>>>>>>>>>>>>> Decider.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> You forget the question that the Halt Decider is
>>>>>>>>>>>>>>>>>>> being asked to solve, which is what the machine
>>>>>>>>>>>>>>>>>>> represented by its input would do.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It is common knowledge that the correct and complete
>>>>>>>>>>>>>>>>>> simulation of a machine description always provides
>>>>>>>>>>>>>>>>>> the actual behavior specified by this machine
>>>>>>>>>>>>>>>>>> description.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Right.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> That you (and others such as Ben) reject that the
>>>>>>>>>>>>>>>>>> correct and complete simulation by H(P,P) of its
>>>>>>>>>>>>>>>>>> input does provide the actual behavior of this input
>>>>>>>>>>>>>>>>>> also rejects the notion of a UTM which you accept,
>>>>>>>>>>>>>>>>>> thus you (and all others holding this view such as
>>>>>>>>>>>>>>>>>> Ben) contradict yourself (themselves).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> So, why do you reject the actual correct and complete
>>>>>>>>>>>>>>>>> simulation of the input to H when done by an actual
>>>>>>>>>>>>>>>>> pure simulator/UTM?
>>>>>>>>>>>>>>>> As long as it is done at the exact point in the
>>>>>>>>>>>>>>>> execution trace as H(P,P) then it is fine, otherwise
>>>>>>>>>>>>>>>> it is not the same as the simulation by H(P,P).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The simulation of the input to H(P,P) is the simulation
>>>>>>>>>>>>>>> of the instruction sequence specified by the code of P
>>>>>>>>>>>>>>> (and the routines it calls) and has ZERO dependency on
>>>>>>>>>>>>>>> what happened before that call
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> main()
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>    P(P); // depends on the return value from H(P,P);
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The input to H(P,P) that H correctly simulates cannot
>>>>>>>>>>>>>> possibly depend on the return value from H because this
>>>>>>>>>>>>>> return value is unreachable by P:
>>>>>>>>>>>>>
>>>>>>>>>>>>> But it NEEDS to. That fact that it can't get the needed
>>>>>>>>>>>>> value because of the limitation of your algorithm, doesn't
>>>>>>>>>>>>> mean it gets to ignore it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Not, Mr Flibble has shown a way that H CAN determine the
>>>>>>>>>>>>> behavior of P based on the return value of H, even though
>>>>>>>>>>>>> H can simulate the path through itself.
>>>>>>>>>>>>>
>>>>>>>>>>>>> (As I pointed out a long time ago too).
>>>>>>>>>>>>
>>>>>>>>>>>> Every function that is called in infinite recursion cannot
>>>>>>>>>>>> possibly correctly return to its caller. People that
>>>>>>>>>>>> believe that it can are as wrong as if they disagreed with
>>>>>>>>>>>> arithmetic.
>>>>>>>>>>>
>>>>>>>>>>> Your thinking isn't joined up. The Flibble Signaling Halt
>>>>>>>>>>> Decider (TM) is *not* infinitely recursive (as you have been
>>>>>>>>>>> told many times) so of course it is quite valid for it to
>>>>>>>>>>> return a value to its caller. The only thing that suffers
>>>>>>>>>>> from infinite recursion is your broken mess.
>>>>>>>>>>>>
>>>>>>>>>>>> If computer science says that a function called in finite
>>>>>>>>>>>> recursion must return to its caller then computer science
>>>>>>>>>>>> is wrong, one might as well have said the cats must be
>>>>>>>>>>>> dogs.
>>>>>>>>>>>
>>>>>>>>>>> I assume you meant "infinite recursion". A function that
>>>>>>>>>>> returns a value to its caller is *by definition* not
>>>>>>>>>>> infinitely recursive.
>>>>>>>>>>>
>>>>>>>>>>> The Flibble Signaling Halt Decider (TM) just works, your
>>>>>>>>>>> mess does not.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> You claim to be a "computer scientist" yet do not even
>>>>>>>>>> understand the concept of unreachable code:
>>>>>>>>>>
>>>>>>>>>> void P(ptr x)
>>>>>>>>>> {
>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>> if (Halt_Status)
>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>> return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> int main()
>>>>>>>>>> {
>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>>>>>>>>>> (b) that simulates P(P) that calls a simulated H(P,P)
>>>>>>>>>> (c) that simulates P(P) that calls a simulated H(P,P)
>>>>>>>>>> (d) that simulates P(P) that calls a simulated H(P,P)...
>>>>>>>>>> *Until H aborts its simulation*
>>>>>>>>>
>>>>>>>>> Virtually every reply you make now totally ignores what you
>>>>>>>>> are replying to and instead is just regurgitation of the the
>>>>>>>>> same old shit.
>>>>>>>>>
>>>>>>>>> I have shown on several occasions in replies to you that I
>>>>>>>>> fully understand the concept of unreachable code.
>>>>>>>>>
>>>>>>>>> Again: the Flibble Signaling Halt Decider (TM) is *NOT*
>>>>>>>>> recursive so your traces don't apply to it, your traces only
>>>>>>>>> apply to your broken mess which has to "abort" the infinite
>>>>>>>>> recursion which is YOUR design mistake.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>
>>>>>>>> Although H(P,P) does recognize and abort the simulation of its
>>>>>>>> input before the first recursive call is invoked, it remains an
>>>>>>>> easily verified fact that P specifies infinitely recursive
>>>>>>>> simulation to every simulating halt decider.
>>>>>>>
>>>>>>> Obviously not a verified fact given the Flibble Signaling Halt
>>>>>>> Decider (TM) is an example of a simulating halt decider that is
>>>>>>> *not* recursive ergo there is no recursive simulation: instead
>>>>>>> there is a forking simulation that allows the decider to return
>>>>>>> a value to its caller in each fork.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> When H(P,P) simulates exactly what its input specifies:
>>>>>> no more and no less then this behavior results:
>>>>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>>>>>> (b) that simulates P(P) that calls a simulated H(P,P)
>>>>>> (c) that simulates P(P) that calls a simulated H(P,P)
>>>>>> (d) that simulates P(P) that calls a simulated H(P,P)...
>>>>>> *Until H aborts its simulation*
>>>>>>
>>>>>> When H(P,P) simulates anything besides exactly what its input
>>>>>> specifies then its simulation is incorrect.
>>>>>
>>>>> Nope, the definition of a halt decider does not specify that a
>>>>> simulating halt decider must be recursive in nature.
>>>>>
>>>>
>>>> The definition of correct simulation requires that the line-by-line
>>>> execution trace derived from simulation exactly matches the
>>>> behavior specified by the line-by-line source-code of the
>>>> simulated input.
>>>>
>>>> Mine does that, your does not, thus mine is correct and yours is
>>>> incorrect.
>>>
>>> Mine does that, yours does not, thus mine is correct and yours
>>> is incorrect: if P(P) halts then H(P,P) must return a value of 1
>>> irregardless of whether it is a simulating halt decider or not.
>>>
>>> /Flibble
>>>
>>
>> So you disagree that a correct x86 emulation of the input to H(P,P)
>> must show line-by-line that the execution trace of the simulated
>> input exactly matches the x86 source-code of this input?
>> (a) Yes you disagree
>> (b) No you do not disagree.
>>
>> Ant answer not having Yes or No will be considered a dishonest dodge.
>
> People cannot answer that question until you and everybody else agree
> what the question actually means because you seem to think the "source
> code of the input" only consists of source code in P up to the point of
> the call to H whilst everybody else thinks that it includes the source
> after the call to H *because* to be a valid halt decider H must return
> a value to its caller; yours "aborts" your fucktarded "infinite
> recursion" instead and is thus not a valid halt decider for
> non-pathological input. If P(P) halts then H(P,P) must return 1.
>
> /Flibble
>

On 8/22/22 10:31 AM, olcott wrote:
> On 8/21/2022 10:37 PM, Richard Damon wrote:
>> On 8/21/22 11:27 PM, olcott wrote:
>>> On 8/21/2022 10:14 PM, Richard Damon wrote:
>>>> On 8/21/22 9:37 PM, olcott wrote:
>>>>> On 8/21/2022 8:04 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 8/21/22 8:45 PM, olcott wrote:
>>>>>>> On 8/21/2022 1:04 PM, Richard Damon wrote:
>>>>>>>> On 8/21/22 11:36 AM, olcott wrote:
>>>>>>>>> On 8/21/2022 10:16 AM, Shvili, the Kookologist wrote:
>>>>>>>>>> On Sat, 20 Aug 2022 16:01:31 -0500, in article <crudnRbncP4E1pz-
>>>>>>>>>> nZ2dnZfqlJzNnZ2d@giganews.com>, olcott wrote:
>>>>>>>>>>
>>>>>>>>>> [snip]
>>>>>>>>>>
>>>>>>>>>>> It is common knowledge that [...]
>>>>>>>>>>
>>>>>>>>>> Have you noticed that almost every time you use this phrase,
>>>>>>>>>> you're
>>>>>>>>>> wrong?
>>>>>>>>>> So also this time.
>>>>>>>>>>
>>>>>>>>>>> [...] the correct and complete simulation of a
>>>>>>>>>>> machine description [...]
>>>>>>>>>>
>>>>>>>>>> Machine descriptions are never simulated -- they're just
>>>>>>>>>> sequences
>>>>>>>>>> of symbols.
>>>>>>>>>> and don't have any defined behaviour. The machines they
>>>>>>>>>> *represent*
>>>>>>>>>> may be
>>>>>>>>>> simulated.
>>>>>>>>>>
>>>>>>>>>>> [...] always provides the actual behavior specified by
>>>>>>>>>>> this machine description.
>>>>>>>>>>
>>>>>>>>>> This is almost, but not quite, correct (if you fix it
>>>>>>>>>> according to
>>>>>>>>>> the
>>>>>>>>>> previous paragraph). It would have been completely correct, if it
>>>>>>>>>> weren't
>>>>>>>>>> for the fact that you're using an utterly bizarre meaning for the
>>>>>>>>>> phrase
>>>>>>>>>> "the actual behavior specified by this machine description".
>>>>>>>>>>
>>>>>>>>>>> That you and others reject this when it is applied to my
>>>>>>>>>>> simulating halt
>>>>>>>>>>> decider implicitly rejects the notion of a UTM. Since you and
>>>>>>>>>>> others do
>>>>>>>>>>> accept the notion of a UTM, I have just proven that your
>>>>>>>>>>> reasoning is
>>>>>>>>>>> incoherent and/or inconsistent.
>>>>>>>>>>
>>>>>>>>>> Let M be a given machine, with machine description [M], and let w
>>>>>>>>>> be
>>>>>>>>>> a given input tape, with tape description [w]. Then the
>>>>>>>>>> "simulation"
>>>>>>>>>> UTM([M],[w]) has exactly the same result (i.e. exactly the same
>>>>>>>>>> behaviour)
>>>>>>>>>> as the direct computation M(w). This is actually the
>>>>>>>>>> definition of
>>>>>>>>>> a UTM.
>>>>>>>>>>
>>>>>>>>>> Another way of expressing this is: M(w) and UTM([M],[w]) compute
>>>>>>>>>> the same
>>>>>>>>>> partial function.
>>>>>>>>>>
>>>>>>>>>> You have made it abundantly clear that when you say "the actual
>>>>>>>>>> behavior
>>>>>>>>>> specified by this machine description", you do *not* mean "the
>>>>>>>>>> actual
>>>>>>>>>> behavior specified by this machine description", because that's
>>>>>>>>>> simply
>>>>>>>>>> the behaviour of M(w). What you *do* mean is "the behaviour of
>>>>>>>>>> your
>>>>>>>>>> particular, broken and incomplete, quasi-simulation based on [M]
>>>>>>>>>> and [w]".
>>>>>>>>>>
>>>>>>>>>> Why is it broken? Because it *doesn't* have the same behaviour
>>>>>>>>>> as M
>>>>>>>>>> (w),
>>>>>>>>>> nor as UTM([M],[w]). A correct simulation *means* that it has the
>>>>>>>>>> same
>>>>>>>>>> behaviour as M(w).
>>>>>>>>>>
>>>>>>>>>> Why is it incomplete? Because it aborts its "simulation"
>>>>>>>>>> before it
>>>>>>>>>> reaches
>>>>>>>>>> a halting configuration of the machine represented by its input,
>>>>>>>>>> and it
>>>>>>>>>> does so on invalidly.
>>>>>>>>>>
>>>>>>>>>> Why is it a quasi-simulation? Because it depends on external
>>>>>>>>>> input
>>>>>>>>>> that is
>>>>>>>>>> contained in neither [M] nor [w]. You have said, on numerous
>>>>>>>>>> occasions,
>>>>>>>>>> that the behaviour of your "H(P,P)" depends on the specific
>>>>>>>>>> memory
>>>>>>>>>> location of "P". Well, then that location is an external input.
>>>>>>>>>> Your H is
>>>>>>>>>> *not* analogous to Linz' H([M],[w]).
>>>>>>>>>>
>>>>>>>>>> This is the point where you usually barf up your stanza about how
>>>>>>>>>> the
>>>>>>>>>> behaviour of your "H(P,P)" cannot be expected to be computed
>>>>>>>>>> "from
>>>>>>>>>> the
>>>>>>>>>> non-input P(P)". This is obviously idiotic, for the following
>>>>>>>>>> reasons:
>>>>>>>>>>
>>>>>>>>>> 1) A purported halt decider H([M],[w]) is *not* required to
>>>>>>>>>> compute
>>>>>>>>>> its
>>>>>>>>>>     result *from* M(w), but to *match* M(w). Computing *from*
>>>>>>>>>> M(w)
>>>>>>>>>> would be
>>>>>>>>>>     completely pointless, because the decider would already
>>>>>>>>>> know the
>>>>>>>>>> answer.
>>>>>>>>>>
>>>>>>>>>>     Since you seem unable to understand anything but arguments
>>>>>>>>>> from
>>>>>>>>>>     analogy, let me re-use one that you yourself have employed:
>>>>>>>>>> Suppose
>>>>>>>>>>     we want to construct an addition algorithm add(x,y). If
>>>>>>>>>> you were
>>>>>>>>>> to
>>>>>>>>>>     complain that add(5,7) cannot be required to compute its
>>>>>>>>>> result
>>>>>>>>>> "from
>>>>>>>>>>     the non-input 12", you would, quite rightly, be regarded as a
>>>>>>>>>> complete
>>>>>>>>>>     nitwit. Can you now guess why you're universally regarded
>>>>>>>>>> as a
>>>>>>>>>> complete
>>>>>>>>>>     nitwit?
>>>>>>>>>>
>>>>>>>>>> 2) The behaviour of UTM([M],[w]) is *defined* to match the
>>>>>>>>>> behaviour of M(w),
>>>>>>>>>>     and UTMs very evidently do exist. The information
>>>>>>>>>> contained in
>>>>>>>>>> [M] and [w]
>>>>>>>>>>     is obviously enough to match the behaviour of M(w). The fact
>>>>>>>>>> that your
>>>>>>>>>>     "simulator" fails in this regard, is proof that your
>>>>>>>>>> "simulator" is
>>>>>>>>>>     defective -- *not* that you have discovered a "loop hole", or
>>>>>>>>>> that halting
>>>>>>>>>>     theorem is faulty, or anything of that kind -- only that
>>>>>>>>>> you're
>>>>>>>>>> working
>>>>>>>>>>     with a broken simulator.
>>>>>>>>>>
>>>>>>>>>>> *NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE THERE IS NO
>>>>>>>>>>> ERROR*
>>>>>>>>>>
>>>>>>>>>> A lot of people have pointed out many kinds of errors in your
>>>>>>>>>> reasoning.
>>>>>>>>>> You usually respond with some form "proof by regurgitation". I
>>>>>>>>>> expect you
>>>>>>>>>> will do so to this post.
>>>>>>>>>>
>>>>>>>>>>> When-so-ever a simulating halt decider (SHD) correctly
>>>>>>>>>>> performs a
>>>>>>>>>>> partial simulation of its input and the behavior of this partial
>>>>>>>>>>> simulation correctly matches a non-halting behavior pattern
>>>>>>>>>>> then the SHD
>>>>>>>>>>> halt decider can correctly report non-halting.
>>>>>>>>>>>
>>>>>>>>>>> A non-halting behavior pattern is correct when-so-ever
>>>>>>>>>>> matching this
>>>>>>>>>>> behavior pattern proves that the correct and complete
>>>>>>>>>>> simulation of the
>>>>>>>>>>> input by SHD would never reach the final state of this
>>>>>>>>>>> simulated input.
>>>>>>>>>>
>>>>>>>>>> Yeah, that's just a bunch of equivocations on "correctly", "its
>>>>>>>>>> input",
>>>>>>>>>> "non-halting behavior", and more.  Please learn to write clearly.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Also, could you *please* stop misreading Linz! He *doesn't* say
>>>>>>>>>> that a TM
>>>>>>>>>> halts, only if it enters a "final state". What he actually
>>>>>>>>>> says is:
>>>>>>>>>>
>>>>>>>>>>      "A Turing machine is said to halt whenever it reaches a
>>>>>>>>>> configuration
>>>>>>>>>>      for which delta is not defined; this is possible because
>>>>>>>>>> delta
>>>>>>>>>> is a
>>>>>>>>>>      partial function. In fact, we will assume that no
>>>>>>>>>> transitions
>>>>>>>>>> are
>>>>>>>>>>      defined for any final state, so the Turing machine will halt
>>>>>>>>>> whenever
>>>>>>>>>>      it enters a final state."
>>>>>>>>>>
>>>>>>>>>> So, for a general TM, there may well be configurations for which
>>>>>>>>>> the TM
>>>>>>>>>> halts in a non-final state. It is, on the other hand, understood
>>>>>>>>>> that a TM
>>>>>>>>>> *only* stops running if enters a configuration for which the
>>>>>>>>>> transition
>>>>>>>>>> function is undefined.
>>>>>>>>>>
>>>>>>>>>> "Final states" only concern the *interpretation* of the value
>>>>>>>>>> of a
>>>>>>>>>> computation -- *not* whether the TM halts or not.
>>>>>>>>>>
>>>>>>>>>> This means that "halting" and "stops running" are the exact the
>>>>>>>>>> same things.
>>>>>>>>>> And obviously, "running" and "being simulated" are two entirely
>>>>>>>>>> different
>>>>>>>>>> things.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> void P(ptr x)
>>>>>>>>> {
>>>>>>>>>    int Halt_Status = UTM(x, x);
>>>>>>>>>    if (Halt_Status)
>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>    return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> The behavior of the actual input to the simulating halt decider
>>>>>>>>> is the behavior of the above. Since C functions do not actually
>>>>>>>>> have UTM's a more accurate way of sayoing this is:
>>>>>>>>>
>>>>>>>>> void P(ptr x)
>>>>>>>>> {
>>>>>>>>>    int Halt_Status = Simulate(x, x);
>>>>>>>>>    if (Halt_Status)
>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>    return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> The behavior of UTM(P,P) or Simulate(P,P) is not the behavior
>>>>>>>>> of the actual input to H(P,P) because it is at a different
>>>>>>>>> point in the execution trace than H(P,P).
>>>>>>>>>
>>>>>>>>
>>>>>>>> Wrong, at least if H is supposed to be a Halt Decider.
>>>>>>>>
>>>>>>>> You forget the question that the Halt Decider is being asked to
>>>>>>>> solve, which is what the machine represented by its input would do.
>>>>>>>>
>>>>>>>
>>>>>>> It is common knowledge that the correct and complete simulation
>>>>>>> of a machine description always provides the actual behavior
>>>>>>> specified by this machine description.
>>>>>>
>>>>>> Right.
>>>>>>
>>>>>>>
>>>>>>> That you (and others such as Ben) reject that the correct and
>>>>>>> complete simulation by H(P,P) of its input does provide the
>>>>>>> actual behavior of this input also rejects the notion of a UTM
>>>>>>> which you accept, thus you (and all others holding this view such
>>>>>>> as Ben) contradict yourself (themselves).
>>>>>>>
>>>>>>
>>>>>> So, why do you reject the actual correct and complete simulation
>>>>>> of the input to H when done by an actual pure simulator/UTM?
>>>>>>
>>>>> As long as it is done at the exact point in the execution trace as
>>>>> H(P,P) then it is fine, otherwise it is not the same as the
>>>>> simulation by H(P,P).
>>>>>
>>>>
>>>> The simulation of the input to H(P,P) is the simulation of the
>>>> instruction sequence specified by the code of P (and the routines it
>>>> calls) and has ZERO dependency on what happened before that call
>>>
>>> main()
>>> {
>>>    P(P); // depends on the return value from H(P,P);
>>> }
>>>
>>> The input to H(P,P) that H correctly simulates cannot possibly depend
>>> on the return value from H because this return value is unreachable
>>> by P:
>>
>> But it NEEDS to. That fact that it can't get the needed value because
>> of the limitation of your algorithm, doesn't mean it gets to ignore it.
>>
>> Not, Mr Flibble has shown a way that H CAN determine the behavior of P
>> based on the return value of H, even though H can simulate the path
>> through itself.
>>
>> (As I pointed out a long time ago too).
>
> Every function that is called in infinite recursion cannot possibly
> correctly return to its caller. People that believe that it can are as
> wrong as if they disagreed with arithmetic.
>
> If computer science says that a function called in finite recursion must
> return to its caller then computer science is wrong, one might as well
> have said the cats must be dogs.
>
>>>
>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>>> (b) that simulates P(P) that calls a simulated H(P,P)
>>> (c) that simulates P(P) that calls a simulated H(P,P)
>>> (d) that simulates P(P) that calls a simulated H(P,P)...
>>> *Until H aborts its simulation*
>>>
>>> This dependency difference causes the different behavior between the
>>> simulated P and the executed P.
>>
>> Nope, the CORRECT AND COMPLETE simulation of the input does depend on
>> the value that H(P,P) returns, unless H(P,P) never returns a value to
>> ANYBODY.
>>
>> Your H just gets it wrong because it "guesses" wrong because it used
>> unsound logic.
>>
>
> You know that it did not merely guess.
> You know that the correct and complete simulation by H(P,P) of its input
> would never reach the final state of this input.

On 8/22/22 3:33 PM, olcott wrote:
> On 8/22/2022 2:24 PM, Mr Flibble wrote:
>> On Mon, 22 Aug 2022 13:37:11 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 8/22/2022 1:11 PM, Mr Flibble wrote:
>>>> On Mon, 22 Aug 2022 13:02:07 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>> On 8/22/2022 12:53 PM, Mr Flibble wrote:
>>>>>> On Mon, 22 Aug 2022 12:50:20 -0500
>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>> On 8/22/2022 12:43 PM, Mr Flibble wrote:
>>>>>>>> On Mon, 22 Aug 2022 12:39:41 -0500
>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>> On 8/22/2022 12:15 PM, Mr Flibble wrote:
>>>>>>>>>> On Mon, 22 Aug 2022 12:04:11 -0500
>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>> On 8/22/2022 11:21 AM, Mr Flibble wrote:
>>>>>>>>>>>> On Mon, 22 Aug 2022 09:31:47 -0500
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>> On 8/21/2022 10:37 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 8/21/22 11:27 PM, olcott wrote:
>>>>>>>>>>>>>>> On 8/21/2022 10:14 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 8/21/22 9:37 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 8/21/2022 8:04 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 8/21/22 8:45 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 8/21/2022 1:04 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 8/21/22 11:36 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 8/21/2022 10:16 AM, Shvili, the Kookologist
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>> On Sat, 20 Aug 2022 16:01:31 -0500, in article
>>>>>>>>>>>>>>>>>>>>>> <crudnRbncP4E1pz- nZ2dnZfqlJzNnZ2d@giganews.com>,
>>>>>>>>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> [snip]
>>>>>>>>>>>>>>>>>>>>>>> It is common knowledge that [...]
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Have you noticed that almost every time you use
>>>>>>>>>>>>>>>>>>>>>> this phrase, you're
>>>>>>>>>>>>>>>>>>>>>> wrong?
>>>>>>>>>>>>>>>>>>>>>> So also this time.
>>>>>>>>>>>>>>>>>>>>>>> [...] the correct and complete simulation of a
>>>>>>>>>>>>>>>>>>>>>>> machine description [...]
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Machine descriptions are never simulated --
>>>>>>>>>>>>>>>>>>>>>> they're just sequences of symbols.
>>>>>>>>>>>>>>>>>>>>>> and don't have any defined behaviour. The machines
>>>>>>>>>>>>>>>>>>>>>> they *represent*
>>>>>>>>>>>>>>>>>>>>>> may be
>>>>>>>>>>>>>>>>>>>>>> simulated.
>>>>>>>>>>>>>>>>>>>>>>> [...] always provides the actual behavior
>>>>>>>>>>>>>>>>>>>>>>> specified by this machine description.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> This is almost, but not quite, correct (if you fix
>>>>>>>>>>>>>>>>>>>>>> it according to the
>>>>>>>>>>>>>>>>>>>>>> previous paragraph). It would have been completely
>>>>>>>>>>>>>>>>>>>>>> correct, if it weren't
>>>>>>>>>>>>>>>>>>>>>> for the fact that you're using an utterly bizarre
>>>>>>>>>>>>>>>>>>>>>> meaning for the phrase
>>>>>>>>>>>>>>>>>>>>>> "the actual behavior specified by this machine
>>>>>>>>>>>>>>>>>>>>>> description".
>>>>>>>>>>>>>>>>>>>>>>> That you and others reject this when it is
>>>>>>>>>>>>>>>>>>>>>>> applied to my simulating halt
>>>>>>>>>>>>>>>>>>>>>>> decider implicitly rejects the notion of a UTM.
>>>>>>>>>>>>>>>>>>>>>>> Since you and others do
>>>>>>>>>>>>>>>>>>>>>>> accept the notion of a UTM, I have just proven
>>>>>>>>>>>>>>>>>>>>>>> that your reasoning is
>>>>>>>>>>>>>>>>>>>>>>> incoherent and/or inconsistent.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Let M be a given machine, with machine description
>>>>>>>>>>>>>>>>>>>>>> [M], and let w be
>>>>>>>>>>>>>>>>>>>>>> a given input tape, with tape description [w].
>>>>>>>>>>>>>>>>>>>>>> Then the "simulation"
>>>>>>>>>>>>>>>>>>>>>> UTM([M],[w]) has exactly the same result (i.e.
>>>>>>>>>>>>>>>>>>>>>> exactly the same behaviour)
>>>>>>>>>>>>>>>>>>>>>> as the direct computation M(w). This is actually
>>>>>>>>>>>>>>>>>>>>>> the definition of a UTM.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Another way of expressing this is: M(w) and
>>>>>>>>>>>>>>>>>>>>>> UTM([M],[w]) compute the same
>>>>>>>>>>>>>>>>>>>>>> partial function.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> You have made it abundantly clear that when you
>>>>>>>>>>>>>>>>>>>>>> say "the actual behavior
>>>>>>>>>>>>>>>>>>>>>> specified by this machine description", you do
>>>>>>>>>>>>>>>>>>>>>> *not* mean "the actual
>>>>>>>>>>>>>>>>>>>>>> behavior specified by this machine description",
>>>>>>>>>>>>>>>>>>>>>> because that's simply
>>>>>>>>>>>>>>>>>>>>>> the behaviour of M(w). What you *do* mean is "the
>>>>>>>>>>>>>>>>>>>>>> behaviour of your
>>>>>>>>>>>>>>>>>>>>>> particular, broken and incomplete,
>>>>>>>>>>>>>>>>>>>>>> quasi-simulation based on [M] and [w]".
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Why is it broken? Because it *doesn't* have the
>>>>>>>>>>>>>>>>>>>>>> same behaviour as M
>>>>>>>>>>>>>>>>>>>>>> (w),
>>>>>>>>>>>>>>>>>>>>>> nor as UTM([M],[w]). A correct simulation *means*
>>>>>>>>>>>>>>>>>>>>>> that it has the same
>>>>>>>>>>>>>>>>>>>>>> behaviour as M(w).
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Why is it incomplete? Because it aborts its
>>>>>>>>>>>>>>>>>>>>>> "simulation" before it reaches
>>>>>>>>>>>>>>>>>>>>>> a halting configuration of the machine represented
>>>>>>>>>>>>>>>>>>>>>> by its input, and it
>>>>>>>>>>>>>>>>>>>>>> does so on invalidly.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Why is it a quasi-simulation? Because it depends
>>>>>>>>>>>>>>>>>>>>>> on external input that is
>>>>>>>>>>>>>>>>>>>>>> contained in neither [M] nor [w]. You have said,
>>>>>>>>>>>>>>>>>>>>>> on numerous occasions,
>>>>>>>>>>>>>>>>>>>>>> that the behaviour of your "H(P,P)" depends on the
>>>>>>>>>>>>>>>>>>>>>> specific memory location of "P". Well, then that
>>>>>>>>>>>>>>>>>>>>>> location is an external input. Your H is
>>>>>>>>>>>>>>>>>>>>>> *not* analogous to Linz' H([M],[w]).
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> This is the point where you usually barf up your
>>>>>>>>>>>>>>>>>>>>>> stanza about how the
>>>>>>>>>>>>>>>>>>>>>> behaviour of your "H(P,P)" cannot be expected to
>>>>>>>>>>>>>>>>>>>>>> be computed "from the
>>>>>>>>>>>>>>>>>>>>>> non-input P(P)". This is obviously idiotic, for
>>>>>>>>>>>>>>>>>>>>>> the following reasons:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 1) A purported halt decider H([M],[w]) is *not*
>>>>>>>>>>>>>>>>>>>>>> required to compute
>>>>>>>>>>>>>>>>>>>>>> its
>>>>>>>>>>>>>>>>>>>>>>           result *from* M(w), but to *match* M(w).
>>>>>>>>>>>>>>>>>>>>>> Computing *from* M(w) would be
>>>>>>>>>>>>>>>>>>>>>>           completely pointless, because the decider
>>>>>>>>>>>>>>>>>>>>>> would already know the
>>>>>>>>>>>>>>>>>>>>>> answer.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>           Since you seem unable to understand
>>>>>>>>>>>>>>>>>>>>>> anything but arguments from
>>>>>>>>>>>>>>>>>>>>>>           analogy, let me re-use one that you
>>>>>>>>>>>>>>>>>>>>>> yourself have employed: Suppose
>>>>>>>>>>>>>>>>>>>>>>           we want to construct an addition
>>>>>>>>>>>>>>>>>>>>>> algorithm add(x,y). If you were
>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>           complain that add(5,7) cannot be
>>>>>>>>>>>>>>>>>>>>>> required to compute its result
>>>>>>>>>>>>>>>>>>>>>> "from
>>>>>>>>>>>>>>>>>>>>>>           the non-input 12", you would, quite
>>>>>>>>>>>>>>>>>>>>>> rightly, be regarded as a complete
>>>>>>>>>>>>>>>>>>>>>>           nitwit. Can you now guess why you're
>>>>>>>>>>>>>>>>>>>>>> universally regarded as a complete
>>>>>>>>>>>>>>>>>>>>>>           nitwit?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 2) The behaviour of UTM([M],[w]) is *defined* to
>>>>>>>>>>>>>>>>>>>>>> match the behaviour of M(w),
>>>>>>>>>>>>>>>>>>>>>>           and UTMs very evidently do exist. The
>>>>>>>>>>>>>>>>>>>>>> information contained in [M] and [w]
>>>>>>>>>>>>>>>>>>>>>>           is obviously enough to match the
>>>>>>>>>>>>>>>>>>>>>> behaviour of M(w). The fact that your
>>>>>>>>>>>>>>>>>>>>>>           "simulator" fails in this regard, is
>>>>>>>>>>>>>>>>>>>>>> proof that your "simulator" is
>>>>>>>>>>>>>>>>>>>>>>           defective -- *not* that you have
>>>>>>>>>>>>>>>>>>>>>> discovered a "loop hole", or that halting
>>>>>>>>>>>>>>>>>>>>>>           theorem is faulty, or anything of that
>>>>>>>>>>>>>>>>>>>>>> kind -- only that you're
>>>>>>>>>>>>>>>>>>>>>> working
>>>>>>>>>>>>>>>>>>>>>>           with a broken simulator.
>>>>>>>>>>>>>>>>>>>>>>> *NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE
>>>>>>>>>>>>>>>>>>>>>>> THERE IS NO ERROR*
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> A lot of people have pointed out many kinds of
>>>>>>>>>>>>>>>>>>>>>> errors in your reasoning.
>>>>>>>>>>>>>>>>>>>>>> You usually respond with some form "proof by
>>>>>>>>>>>>>>>>>>>>>> regurgitation". I expect you
>>>>>>>>>>>>>>>>>>>>>> will do so to this post.
>>>>>>>>>>>>>>>>>>>>>>> When-so-ever a simulating halt decider (SHD)
>>>>>>>>>>>>>>>>>>>>>>> correctly performs a partial simulation of its
>>>>>>>>>>>>>>>>>>>>>>> input and the behavior of this partial simulation
>>>>>>>>>>>>>>>>>>>>>>> correctly matches a non-halting behavior pattern
>>>>>>>>>>>>>>>>>>>>>>> then the SHD halt decider can correctly report
>>>>>>>>>>>>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> A non-halting behavior pattern is correct
>>>>>>>>>>>>>>>>>>>>>>> when-so-ever matching this
>>>>>>>>>>>>>>>>>>>>>>> behavior pattern proves that the correct and
>>>>>>>>>>>>>>>>>>>>>>> complete simulation of the
>>>>>>>>>>>>>>>>>>>>>>> input by SHD would never reach the final state of
>>>>>>>>>>>>>>>>>>>>>>> this simulated input.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Yeah, that's just a bunch of equivocations on
>>>>>>>>>>>>>>>>>>>>>> "correctly", "its input",
>>>>>>>>>>>>>>>>>>>>>> "non-halting behavior", and more.  Please learn to
>>>>>>>>>>>>>>>>>>>>>> write clearly.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Also, could you *please* stop misreading Linz! He
>>>>>>>>>>>>>>>>>>>>>> *doesn't* say that a TM
>>>>>>>>>>>>>>>>>>>>>> halts, only if it enters a "final state". What he
>>>>>>>>>>>>>>>>>>>>>> actually says is:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>            "A Turing machine is said to halt
>>>>>>>>>>>>>>>>>>>>>> whenever it reaches a configuration
>>>>>>>>>>>>>>>>>>>>>>            for which delta is not defined; this is
>>>>>>>>>>>>>>>>>>>>>> possible because delta
>>>>>>>>>>>>>>>>>>>>>> is a
>>>>>>>>>>>>>>>>>>>>>>            partial function. In fact, we will
>>>>>>>>>>>>>>>>>>>>>> assume that no transitions are
>>>>>>>>>>>>>>>>>>>>>>            defined for any final state, so the
>>>>>>>>>>>>>>>>>>>>>> Turing machine will halt whenever
>>>>>>>>>>>>>>>>>>>>>>            it enters a final state."
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> So, for a general TM, there may well be
>>>>>>>>>>>>>>>>>>>>>> configurations for which the TM
>>>>>>>>>>>>>>>>>>>>>> halts in a non-final state. It is, on the other
>>>>>>>>>>>>>>>>>>>>>> hand, understood that a TM
>>>>>>>>>>>>>>>>>>>>>> *only* stops running if enters a configuration for
>>>>>>>>>>>>>>>>>>>>>> which the transition
>>>>>>>>>>>>>>>>>>>>>> function is undefined.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> "Final states" only concern the *interpretation*
>>>>>>>>>>>>>>>>>>>>>> of the value of a computation -- *not* whether
>>>>>>>>>>>>>>>>>>>>>> the TM halts or not.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> This means that "halting" and "stops running" are
>>>>>>>>>>>>>>>>>>>>>> the exact the same things.
>>>>>>>>>>>>>>>>>>>>>> And obviously, "running" and "being simulated" are
>>>>>>>>>>>>>>>>>>>>>> two entirely different
>>>>>>>>>>>>>>>>>>>>>> things.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>          int Halt_Status = UTM(x, x);
>>>>>>>>>>>>>>>>>>>>>          if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>            HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>          return;
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The behavior of the actual input to the simulating
>>>>>>>>>>>>>>>>>>>>> halt decider is the behavior of the above. Since C
>>>>>>>>>>>>>>>>>>>>> functions do not actually have UTM's a more
>>>>>>>>>>>>>>>>>>>>> accurate way of sayoing this is:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>          int Halt_Status = Simulate(x, x);
>>>>>>>>>>>>>>>>>>>>>          if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>            HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>          return;
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The behavior of UTM(P,P) or Simulate(P,P) is not
>>>>>>>>>>>>>>>>>>>>> the behavior of the actual input to H(P,P) because
>>>>>>>>>>>>>>>>>>>>> it is at a different point in the execution trace
>>>>>>>>>>>>>>>>>>>>> than H(P,P).
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Wrong, at least if H is supposed to be a Halt
>>>>>>>>>>>>>>>>>>>> Decider.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> You forget the question that the Halt Decider is
>>>>>>>>>>>>>>>>>>>> being asked to solve, which is what the machine
>>>>>>>>>>>>>>>>>>>> represented by its input would do.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> It is common knowledge that the correct and complete
>>>>>>>>>>>>>>>>>>> simulation of a machine description always provides
>>>>>>>>>>>>>>>>>>> the actual behavior specified by this machine
>>>>>>>>>>>>>>>>>>> description.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Right.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> That you (and others such as Ben) reject that the
>>>>>>>>>>>>>>>>>>> correct and complete simulation by H(P,P) of its
>>>>>>>>>>>>>>>>>>> input does provide the actual behavior of this input
>>>>>>>>>>>>>>>>>>> also rejects the notion of a UTM which you accept,
>>>>>>>>>>>>>>>>>>> thus you (and all others holding this view such as
>>>>>>>>>>>>>>>>>>> Ben) contradict yourself (themselves).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> So, why do you reject the actual correct and complete
>>>>>>>>>>>>>>>>>> simulation of the input to H when done by an actual
>>>>>>>>>>>>>>>>>> pure simulator/UTM?
>>>>>>>>>>>>>>>>> As long as it is done at the exact point in the
>>>>>>>>>>>>>>>>> execution trace as H(P,P) then it is fine, otherwise
>>>>>>>>>>>>>>>>> it is not the same as the simulation by H(P,P).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The simulation of the input to H(P,P) is the simulation
>>>>>>>>>>>>>>>> of the instruction sequence specified by the code of P
>>>>>>>>>>>>>>>> (and the routines it calls) and has ZERO dependency on
>>>>>>>>>>>>>>>> what happened before that call
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> main()
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>          P(P); // depends on the return value from H(P,P);
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The input to H(P,P) that H correctly simulates cannot
>>>>>>>>>>>>>>> possibly depend on the return value from H because this
>>>>>>>>>>>>>>> return value is unreachable by P:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But it NEEDS to. That fact that it can't get the needed
>>>>>>>>>>>>>> value because of the limitation of your algorithm, doesn't
>>>>>>>>>>>>>> mean it gets to ignore it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Not, Mr Flibble has shown a way that H CAN determine the
>>>>>>>>>>>>>> behavior of P based on the return value of H, even though
>>>>>>>>>>>>>> H can simulate the path through itself.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> (As I pointed out a long time ago too).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Every function that is called in infinite recursion cannot
>>>>>>>>>>>>> possibly correctly return to its caller. People that
>>>>>>>>>>>>> believe that it can are as wrong as if they disagreed with
>>>>>>>>>>>>> arithmetic.
>>>>>>>>>>>>
>>>>>>>>>>>> Your thinking isn't joined up. The Flibble Signaling Halt
>>>>>>>>>>>> Decider (TM) is *not* infinitely recursive (as you have been
>>>>>>>>>>>> told many times) so of course it is quite valid for it to
>>>>>>>>>>>> return a value to its caller.  The only thing that suffers
>>>>>>>>>>>> from infinite recursion is your broken mess.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If computer science says that a function called in finite
>>>>>>>>>>>>> recursion must return to its caller then computer science
>>>>>>>>>>>>> is wrong, one might as well have said the cats must be
>>>>>>>>>>>>> dogs.
>>>>>>>>>>>>
>>>>>>>>>>>> I assume you meant "infinite recursion". A function that
>>>>>>>>>>>> returns a value to its caller is *by definition* not
>>>>>>>>>>>> infinitely recursive.
>>>>>>>>>>>>
>>>>>>>>>>>> The Flibble Signaling Halt Decider (TM) just works, your
>>>>>>>>>>>> mess does not.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>> You claim to be a "computer scientist" yet do not even
>>>>>>>>>>> understand the concept of unreachable code:
>>>>>>>>>>>
>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>> {
>>>>>>>>>>>         int Halt_Status = H(x, x);
>>>>>>>>>>>         if (Halt_Status)
>>>>>>>>>>>           HERE: goto HERE;
>>>>>>>>>>>         return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> int main()
>>>>>>>>>>> {
>>>>>>>>>>>         Output("Input_Halts = ", H(P, P));
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>>>>>>>>>>> (b) that simulates P(P) that calls a simulated H(P,P)
>>>>>>>>>>> (c) that simulates P(P) that calls a simulated H(P,P)
>>>>>>>>>>> (d) that simulates P(P) that calls a simulated H(P,P)...
>>>>>>>>>>> *Until H aborts its simulation*
>>>>>>>>>>
>>>>>>>>>> Virtually every reply you make now totally ignores what you
>>>>>>>>>> are replying to and instead is just regurgitation of the the
>>>>>>>>>> same old shit.
>>>>>>>>>>
>>>>>>>>>> I have shown on several occasions in replies to you that I
>>>>>>>>>> fully understand the concept of unreachable code.
>>>>>>>>>>
>>>>>>>>>> Again: the Flibble Signaling Halt Decider (TM) is *NOT*
>>>>>>>>>> recursive so your traces don't apply to it, your traces only
>>>>>>>>>> apply to your broken mess which has to "abort" the infinite
>>>>>>>>>> recursion which is YOUR design mistake.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>> Although H(P,P) does recognize and abort the simulation of its
>>>>>>>>> input before the first recursive call is invoked, it remains an
>>>>>>>>> easily verified fact that P specifies infinitely recursive
>>>>>>>>> simulation to every simulating halt decider.
>>>>>>>>
>>>>>>>> Obviously not a verified fact given the Flibble Signaling Halt
>>>>>>>> Decider (TM) is an example of a simulating halt decider that is
>>>>>>>> *not* recursive ergo there is no recursive simulation: instead
>>>>>>>> there is a forking simulation that allows the decider to return
>>>>>>>> a value to its caller in each fork.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>
>>>>>>> When H(P,P) simulates exactly what its input specifies:
>>>>>>> no more and no less then this behavior results:
>>>>>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>>>>>>> (b) that simulates P(P) that calls a simulated H(P,P)
>>>>>>> (c) that simulates P(P) that calls a simulated H(P,P)
>>>>>>> (d) that simulates P(P) that calls a simulated H(P,P)...
>>>>>>> *Until H aborts its simulation*
>>>>>>>
>>>>>>> When H(P,P) simulates anything besides exactly what its input
>>>>>>> specifies then its simulation is incorrect.
>>>>>>
>>>>>> Nope, the definition of a halt decider does not specify that a
>>>>>> simulating halt decider must be recursive in nature.
>>>>>
>>>>> The definition of correct simulation requires that the line-by-line
>>>>> execution trace derived from simulation exactly matches the
>>>>> behavior specified by the line-by-line source-code of the
>>>>> simulated input.
>>>>>
>>>>> Mine does that, your does not, thus mine is correct and yours is
>>>>> incorrect.
>>>>
>>>> Mine does that, yours does not, thus mine is correct and yours
>>>> is incorrect: if P(P) halts then H(P,P) must return a value of 1
>>>> irregardless of whether it is a simulating halt decider or not.
>>>>
>>>> /Flibble
>>>
>>> So you disagree that a correct x86 emulation of the input to H(P,P)
>>> must show line-by-line that the execution trace of the simulated
>>> input exactly matches the x86 source-code of this input?
>>> (a) Yes you disagree
>>> (b) No you do not disagree.
>>>
>>> Ant answer not having Yes or No will be considered a dishonest dodge.
>>
>> People cannot answer that question until you and everybody else agree
>> what the question actually means because you seem to think the "source
>> code of the input" only consists of source code in P up to the point of
>> the call to H whilst everybody else thinks that it includes the source
>> after the call to H *because* to be a valid halt decider H must return
>> a value to its caller; yours "aborts" your fucktarded "infinite
>> recursion" instead and is thus not a valid halt decider for
>> non-pathological input.  If P(P) halts then H(P,P) must return 1.
>>
>> /Flibble
>>
>
> // C source-code for P
> void P(ptr x)
> {
>   int Halt_Status = H(x, x);
>   if (Halt_Status)
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ",  H(P, P));
> }
>
> _P() x86 source-code for P
> [000013c6](01)  55         push ebp
> [000013c7](02)  8bec       mov ebp,esp
> [000013c9](01)  51         push ecx
> [000013ca](03)  8b4508     mov eax,[ebp+08]
> [000013cd](01)  50         push eax
> [000013ce](03)  8b4d08     mov ecx,[ebp+08]
> [000013d1](01)  51         push ecx
> [000013d2](05)  e82ffdffff call 00001106
> [000013d7](03)  83c408     add esp,+08
> [000013da](03)  8945fc     mov [ebp-04],eax
> [000013dd](04)  837dfc00   cmp dword [ebp-04],+00
> [000013e1](02)  7402       jz 000013e5
> [000013e3](02)  ebfe       jmp 000013e3
> [000013e5](02)  8be5       mov esp,ebp
> [000013e7](01)  5d         pop ebp
> [000013e8](01)  c3         ret
> Size in bytes:(0035) [000013e8]
>
> H(P,P) simulates its input and proceeds through machine addresses
> [000013c6] to [000013d2] then ???
>

On 8/22/22 10:25 AM, olcott wrote:
> On 8/21/2022 10:24 PM, Richard Damon wrote:
>> On 8/21/22 9:44 PM, olcott wrote:
>>> On 8/21/2022 8:12 PM, Richard Damon wrote:
>>>>
>>>> On 8/21/22 8:48 PM, olcott wrote:
>>>>> On 8/21/2022 1:09 PM, Richard Damon wrote:
>>>>>> On 8/21/22 9:30 AM, olcott wrote:
>>>>>>> On 8/21/2022 4:00 AM, Mikko wrote:
>>>>>>>> On 2022-08-20 15:01:34 +0000, Fred. Zwarts said:
>>>>>>>>
>>>>>>>>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>>>>>>>>> Olcott, which of the following do you think is more likely?
>>>>>>>>>>
>>>>>>>>>> 1) Olcott is correct and everybody else is wrong.
>>>>>>>>>> 2) Olcott is wrong and everybody else is correct.
>>>>>>>>>>
>>>>>>>>>> Which one is more likely hasn't changed for all the years
>>>>>>>>>> you've been
>>>>>>>>>> attempting to shill your simulating halting decider.  I find
>>>>>>>>>> it amusing
>>>>>>>>>> that I came up with, in less than 24 hours, a simulating halting
>>>>>>>>>> decider that doesn't have the flaws your SHD has.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I have been following these discussions for many months now. I
>>>>>>>>> have a strong impression that there is little progress. It
>>>>>>>>> seems that people are running in circles. I am not an expert in
>>>>>>>>> this field. Maybe it helps if a non-expert tries to summarize
>>>>>>>>> the discussion. Please, be patient when correcting me if I make
>>>>>>>>> any mistake.
>>>>>>>>>
>>>>>>>>> First the problem this is al about:
>>>>>>>>> In computation theory we can denote a program with X and its
>>>>>>>>> input with Y, which together is denoted as X(Y). X(Y) may end
>>>>>>>>> (halt) in a finite number of steps, but another program X
>>>>>>>>> and/or input Y may not halt in a finite number of steps. The
>>>>>>>>> question is, is it possible to create a program H that when
>>>>>>>>> given any program X with its input Y can tell in a finite
>>>>>>>>> number of steps whether X(Y) halts or not? In other words, will
>>>>>>>>> H(X,Y) always halt after a finite number of steps with the
>>>>>>>>> correct answer for any X and Y?
>>>>>>>>
>>>>>>>> In the classical formulation X and H are Turing machines. Y is a
>>>>>>>> finite
>>>>>>>> string of symbols from some finite set. H(X,Y) denotes a
>>>>>>>> computation where
>>>>>>>> H is given a finite string that represents X and Y so that each
>>>>>>>> can be
>>>>>>>> reconstructed.
>>>>>>>>
>>>>>>>>> I hope that this is a correct formulation of the problem.
>>>>>>>>>
>>>>>>>>> The classical proof that it is not possible is the idea that it
>>>>>>>>> is always possible to create a program P that uses H, with
>>>>>>>>> itself as input, but behaves opposite to what H returns. In a
>>>>>>>>> C-like language it would be something like:
>>>>>>>>>
>>>>>>>>> void P(ptr x)
>>>>>>>>> {
>>>>>>>>>    int Halt_Status = H(x, x);
>>>>>>>>>    if (Halt_Status)
>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>    return;
>>>>>>>>> }
>>>>>>>>
>>>>>>>> Roughly so but both P and H take a single string as argument:
>>>>>>>>
>>>>>>>> void P(string x)
>>>>>>>> {
>>>>>>>>   string arg = pair(x, x);
>>>>>>>>   boolean Halt_Status = H(arg);
>>>>>>>>   if (Halt_Status)
>>>>>>>>     HERE: goto HERE;
>>>>>>>>   return;
>>>>>>>> }
>>>>>>>>
>>>>>>>>> If there would be a hypothetical non-simulating non-aborting H,
>>>>>>>>> which would always halts with the correct answer, then it is
>>>>>>>>> clear that there would be a contradiction if we ask H about P
>>>>>>>>> with H(P,P). Because there are only three possibilities:
>>>>>>>>> 1. If H would return true (halting) in a finite number of
>>>>>>>>> steps, then P would start an endless loop, so H(P,P) does not
>>>>>>>>> halt in a finite number of steps.
>>>>>>>>> 2. If H would return false (non-halting) in a finite number of
>>>>>>>>> steps, then P returns immediately, so H returns a wrong result.
>>>>>>>>> 3. If H does not return, then it does not return in a finite
>>>>>>>>> number of steps, so it is not the H where the problem asked for.
>>>>>>>>
>>>>>>>> With Turing machines the possibilities are:
>>>>>>>> 1. H halts with the answer true.
>>>>>>>> 2. H halts with the answer false.
>>>>>>>> 3. H halts but answers neither true nor false.
>>>>>>>> 4. H does not halt.
>>>>>>>>
>>>>>>>> If 3 or 4 happens then H is not a halt decider, i.e., not a
>>>>>>>> solution
>>>>>>>> to the problem. If H(P, P) halts with the answer true then P(P)
>>>>>>>> does
>>>>>>>> not halt so H is not a halt decider. If H(P, P) halts with the
>>>>>>>> answer false then P(P) halts so H is not a halt decider.
>>>>>>>>
>>>>>>>> The restriction to non-simulating non-aborting H is not necessary.
>>>>>>>> The requirements are the same anyway.
>>>>>>>>
>>>>>>>>> I think everybody agrees up to this point.
>>>>>>>>>
>>>>>>>>> Now Olcott has created a simulating aborting H, which, when
>>>>>>>>> given P with input P [so H(P,P)], creates a trace of the
>>>>>>>>> execution and at the point where P calls H, it uses the
>>>>>>>>> following logic: If H were the hypothetical non-aborting H,
>>>>>>>>> then an infinite recursion would happen at this point.
>>>>>>>>> Therefore, Olcott's simulating H aborts the simulation and
>>>>>>>>> returns false (0).
>>>>>>>>>
>>>>>>>>> Does everybody still agree up to this point?
>>>>>>>>
>>>>>>>> Yes, and everybody also agrees that P(P) halts.
>>>>>>>>
>>>>>>>
>>>>>>> It is common knowledge that the correct and complete simulation
>>>>>>> of a machine description always provides the actual behavior
>>>>>>> specified by this machine description.
>>>>>>>
>>>>>>> The correct and complete simulation by H(P,P) of its input would
>>>>>>> never reach its final state and halt, thus the input to H(P,P)
>>>>>>> specifies a non-halting sequence of instructions.
>>>>>
>>>>>> Which might make some sense, until we notice that the only H that
>>>>>> actually does a correct and complete simulation of its input, is
>>>>>> the H that doesn't abort its simulation and thus never answers so
>>>>>> fails to be a Halt Decider.
>>>>> *YOU JUST AREN'T BRIGHT ENOUGH TO COMPREHEND THIS*
>>>>> When-so-ever a simulating halt decider (SHD) correctly performs a
>>>>> partial simulation of its input and the behavior of this partial
>>>>> simulation correctly matches a non-halting behavior pattern then
>>>>> the SHD halt decider can correctly report non-halting.
>>>>
>>>> What is the CORRECT non-halting pattern that the simulation of P(P)
>>>> correctly matched.
>>>>
>>>
>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>>> (b) that simulates P(P) that calls a simulated H(P,P)
>>> (c) that simulates P(P) that calls a simulated H(P,P)
>>> (d) that simulates P(P) that calls a simulated H(P,P)...
>>> *Until H aborts its simulation*
>>>
>>>
>>
>> Which isn't a correct non-halting pattern if H ever actually get to
>> the abort,
>
>
> The question is always:
> Would the input simulated by H reach the final state of this input if H
> never aborts its simulation of this input?

On 8/22/2022 6:21 PM, Richard Damon wrote:
> On 8/22/22 10:31 AM, olcott wrote:
>> On 8/21/2022 10:37 PM, Richard Damon wrote:
>>> On 8/21/22 11:27 PM, olcott wrote:
>>>> On 8/21/2022 10:14 PM, Richard Damon wrote:
>>>>> On 8/21/22 9:37 PM, olcott wrote:
>>>>>> On 8/21/2022 8:04 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 8/21/22 8:45 PM, olcott wrote:
>>>>>>>> On 8/21/2022 1:04 PM, Richard Damon wrote:
>>>>>>>>> On 8/21/22 11:36 AM, olcott wrote:
>>>>>>>>>> On 8/21/2022 10:16 AM, Shvili, the Kookologist wrote:
>>>>>>>>>>> On Sat, 20 Aug 2022 16:01:31 -0500, in article <crudnRbncP4E1pz-
>>>>>>>>>>> nZ2dnZfqlJzNnZ2d@giganews.com>, olcott wrote:
>>>>>>>>>>>
>>>>>>>>>>> [snip]
>>>>>>>>>>>
>>>>>>>>>>>> It is common knowledge that [...]
>>>>>>>>>>>
>>>>>>>>>>> Have you noticed that almost every time you use this phrase,
>>>>>>>>>>> you're
>>>>>>>>>>> wrong?
>>>>>>>>>>> So also this time.
>>>>>>>>>>>
>>>>>>>>>>>> [...] the correct and complete simulation of a
>>>>>>>>>>>> machine description [...]
>>>>>>>>>>>
>>>>>>>>>>> Machine descriptions are never simulated -- they're just
>>>>>>>>>>> sequences
>>>>>>>>>>> of symbols.
>>>>>>>>>>> and don't have any defined behaviour. The machines they
>>>>>>>>>>> *represent*
>>>>>>>>>>> may be
>>>>>>>>>>> simulated.
>>>>>>>>>>>
>>>>>>>>>>>> [...] always provides the actual behavior specified by
>>>>>>>>>>>> this machine description.
>>>>>>>>>>>
>>>>>>>>>>> This is almost, but not quite, correct (if you fix it
>>>>>>>>>>> according to
>>>>>>>>>>> the
>>>>>>>>>>> previous paragraph). It would have been completely correct,
>>>>>>>>>>> if it
>>>>>>>>>>> weren't
>>>>>>>>>>> for the fact that you're using an utterly bizarre meaning for
>>>>>>>>>>> the
>>>>>>>>>>> phrase
>>>>>>>>>>> "the actual behavior specified by this machine description".
>>>>>>>>>>>
>>>>>>>>>>>> That you and others reject this when it is applied to my
>>>>>>>>>>>> simulating halt
>>>>>>>>>>>> decider implicitly rejects the notion of a UTM. Since you
>>>>>>>>>>>> and others do
>>>>>>>>>>>> accept the notion of a UTM, I have just proven that your
>>>>>>>>>>>> reasoning is
>>>>>>>>>>>> incoherent and/or inconsistent.
>>>>>>>>>>>
>>>>>>>>>>> Let M be a given machine, with machine description [M], and
>>>>>>>>>>> let w
>>>>>>>>>>> be
>>>>>>>>>>> a given input tape, with tape description [w]. Then the
>>>>>>>>>>> "simulation"
>>>>>>>>>>> UTM([M],[w]) has exactly the same result (i.e. exactly the same
>>>>>>>>>>> behaviour)
>>>>>>>>>>> as the direct computation M(w). This is actually the
>>>>>>>>>>> definition of
>>>>>>>>>>> a UTM.
>>>>>>>>>>>
>>>>>>>>>>> Another way of expressing this is: M(w) and UTM([M],[w]) compute
>>>>>>>>>>> the same
>>>>>>>>>>> partial function.
>>>>>>>>>>>
>>>>>>>>>>> You have made it abundantly clear that when you say "the actual
>>>>>>>>>>> behavior
>>>>>>>>>>> specified by this machine description", you do *not* mean "the
>>>>>>>>>>> actual
>>>>>>>>>>> behavior specified by this machine description", because that's
>>>>>>>>>>> simply
>>>>>>>>>>> the behaviour of M(w). What you *do* mean is "the behaviour
>>>>>>>>>>> of your
>>>>>>>>>>> particular, broken and incomplete, quasi-simulation based on [M]
>>>>>>>>>>> and [w]".
>>>>>>>>>>>
>>>>>>>>>>> Why is it broken? Because it *doesn't* have the same
>>>>>>>>>>> behaviour as M
>>>>>>>>>>> (w),
>>>>>>>>>>> nor as UTM([M],[w]). A correct simulation *means* that it has
>>>>>>>>>>> the
>>>>>>>>>>> same
>>>>>>>>>>> behaviour as M(w).
>>>>>>>>>>>
>>>>>>>>>>> Why is it incomplete? Because it aborts its "simulation"
>>>>>>>>>>> before it
>>>>>>>>>>> reaches
>>>>>>>>>>> a halting configuration of the machine represented by its input,
>>>>>>>>>>> and it
>>>>>>>>>>> does so on invalidly.
>>>>>>>>>>>
>>>>>>>>>>> Why is it a quasi-simulation? Because it depends on external
>>>>>>>>>>> input
>>>>>>>>>>> that is
>>>>>>>>>>> contained in neither [M] nor [w]. You have said, on numerous
>>>>>>>>>>> occasions,
>>>>>>>>>>> that the behaviour of your "H(P,P)" depends on the specific
>>>>>>>>>>> memory
>>>>>>>>>>> location of "P". Well, then that location is an external input.
>>>>>>>>>>> Your H is
>>>>>>>>>>> *not* analogous to Linz' H([M],[w]).
>>>>>>>>>>>
>>>>>>>>>>> This is the point where you usually barf up your stanza about
>>>>>>>>>>> how
>>>>>>>>>>> the
>>>>>>>>>>> behaviour of your "H(P,P)" cannot be expected to be computed
>>>>>>>>>>> "from
>>>>>>>>>>> the
>>>>>>>>>>> non-input P(P)". This is obviously idiotic, for the following
>>>>>>>>>>> reasons:
>>>>>>>>>>>
>>>>>>>>>>> 1) A purported halt decider H([M],[w]) is *not* required to
>>>>>>>>>>> compute
>>>>>>>>>>> its
>>>>>>>>>>>     result *from* M(w), but to *match* M(w). Computing *from*
>>>>>>>>>>> M(w)
>>>>>>>>>>> would be
>>>>>>>>>>>     completely pointless, because the decider would already
>>>>>>>>>>> know the
>>>>>>>>>>> answer.
>>>>>>>>>>>
>>>>>>>>>>>     Since you seem unable to understand anything but
>>>>>>>>>>> arguments from
>>>>>>>>>>>     analogy, let me re-use one that you yourself have employed:
>>>>>>>>>>> Suppose
>>>>>>>>>>>     we want to construct an addition algorithm add(x,y). If
>>>>>>>>>>> you were
>>>>>>>>>>> to
>>>>>>>>>>>     complain that add(5,7) cannot be required to compute its
>>>>>>>>>>> result
>>>>>>>>>>> "from
>>>>>>>>>>>     the non-input 12", you would, quite rightly, be regarded
>>>>>>>>>>> as a
>>>>>>>>>>> complete
>>>>>>>>>>>     nitwit. Can you now guess why you're universally regarded
>>>>>>>>>>> as a
>>>>>>>>>>> complete
>>>>>>>>>>>     nitwit?
>>>>>>>>>>>
>>>>>>>>>>> 2) The behaviour of UTM([M],[w]) is *defined* to match the
>>>>>>>>>>> behaviour of M(w),
>>>>>>>>>>>     and UTMs very evidently do exist. The information
>>>>>>>>>>> contained in
>>>>>>>>>>> [M] and [w]
>>>>>>>>>>>     is obviously enough to match the behaviour of M(w). The fact
>>>>>>>>>>> that your
>>>>>>>>>>>     "simulator" fails in this regard, is proof that your
>>>>>>>>>>> "simulator" is
>>>>>>>>>>>     defective -- *not* that you have discovered a "loop
>>>>>>>>>>> hole", or
>>>>>>>>>>> that halting
>>>>>>>>>>>     theorem is faulty, or anything of that kind -- only that
>>>>>>>>>>> you're
>>>>>>>>>>> working
>>>>>>>>>>>     with a broken simulator.
>>>>>>>>>>>
>>>>>>>>>>>> *NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE THERE IS NO
>>>>>>>>>>>> ERROR*
>>>>>>>>>>>
>>>>>>>>>>> A lot of people have pointed out many kinds of errors in your
>>>>>>>>>>> reasoning.
>>>>>>>>>>> You usually respond with some form "proof by regurgitation". I
>>>>>>>>>>> expect you
>>>>>>>>>>> will do so to this post.
>>>>>>>>>>>
>>>>>>>>>>>> When-so-ever a simulating halt decider (SHD) correctly
>>>>>>>>>>>> performs a
>>>>>>>>>>>> partial simulation of its input and the behavior of this
>>>>>>>>>>>> partial
>>>>>>>>>>>> simulation correctly matches a non-halting behavior pattern
>>>>>>>>>>>> then the SHD
>>>>>>>>>>>> halt decider can correctly report non-halting.
>>>>>>>>>>>>
>>>>>>>>>>>> A non-halting behavior pattern is correct when-so-ever
>>>>>>>>>>>> matching this
>>>>>>>>>>>> behavior pattern proves that the correct and complete
>>>>>>>>>>>> simulation of the
>>>>>>>>>>>> input by SHD would never reach the final state of this
>>>>>>>>>>>> simulated input.
>>>>>>>>>>>
>>>>>>>>>>> Yeah, that's just a bunch of equivocations on "correctly", "its
>>>>>>>>>>> input",
>>>>>>>>>>> "non-halting behavior", and more.  Please learn to write
>>>>>>>>>>> clearly.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Also, could you *please* stop misreading Linz! He *doesn't* say
>>>>>>>>>>> that a TM
>>>>>>>>>>> halts, only if it enters a "final state". What he actually
>>>>>>>>>>> says is:
>>>>>>>>>>>
>>>>>>>>>>>      "A Turing machine is said to halt whenever it reaches a
>>>>>>>>>>> configuration
>>>>>>>>>>>      for which delta is not defined; this is possible because
>>>>>>>>>>> delta
>>>>>>>>>>> is a
>>>>>>>>>>>      partial function. In fact, we will assume that no
>>>>>>>>>>> transitions
>>>>>>>>>>> are
>>>>>>>>>>>      defined for any final state, so the Turing machine will
>>>>>>>>>>> halt
>>>>>>>>>>> whenever
>>>>>>>>>>>      it enters a final state."
>>>>>>>>>>>
>>>>>>>>>>> So, for a general TM, there may well be configurations for which
>>>>>>>>>>> the TM
>>>>>>>>>>> halts in a non-final state. It is, on the other hand, understood
>>>>>>>>>>> that a TM
>>>>>>>>>>> *only* stops running if enters a configuration for which the
>>>>>>>>>>> transition
>>>>>>>>>>> function is undefined.
>>>>>>>>>>>
>>>>>>>>>>> "Final states" only concern the *interpretation* of the value
>>>>>>>>>>> of a
>>>>>>>>>>> computation -- *not* whether the TM halts or not.
>>>>>>>>>>>
>>>>>>>>>>> This means that "halting" and "stops running" are the exact the
>>>>>>>>>>> same things.
>>>>>>>>>>> And obviously, "running" and "being simulated" are two entirely
>>>>>>>>>>> different
>>>>>>>>>>> things.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> void P(ptr x)
>>>>>>>>>> {
>>>>>>>>>>    int Halt_Status = UTM(x, x);
>>>>>>>>>>    if (Halt_Status)
>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>    return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> The behavior of the actual input to the simulating halt
>>>>>>>>>> decider is the behavior of the above. Since C functions do not
>>>>>>>>>> actually have UTM's a more accurate way of sayoing this is:
>>>>>>>>>>
>>>>>>>>>> void P(ptr x)
>>>>>>>>>> {
>>>>>>>>>>    int Halt_Status = Simulate(x, x);
>>>>>>>>>>    if (Halt_Status)
>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>    return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> The behavior of UTM(P,P) or Simulate(P,P) is not the behavior
>>>>>>>>>> of the actual input to H(P,P) because it is at a different
>>>>>>>>>> point in the execution trace than H(P,P).
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Wrong, at least if H is supposed to be a Halt Decider.
>>>>>>>>>
>>>>>>>>> You forget the question that the Halt Decider is being asked to
>>>>>>>>> solve, which is what the machine represented by its input would
>>>>>>>>> do.
>>>>>>>>>
>>>>>>>>
>>>>>>>> It is common knowledge that the correct and complete simulation
>>>>>>>> of a machine description always provides the actual behavior
>>>>>>>> specified by this machine description.
>>>>>>>
>>>>>>> Right.
>>>>>>>
>>>>>>>>
>>>>>>>> That you (and others such as Ben) reject that the correct and
>>>>>>>> complete simulation by H(P,P) of its input does provide the
>>>>>>>> actual behavior of this input also rejects the notion of a UTM
>>>>>>>> which you accept, thus you (and all others holding this view
>>>>>>>> such as Ben) contradict yourself (themselves).
>>>>>>>>
>>>>>>>
>>>>>>> So, why do you reject the actual correct and complete simulation
>>>>>>> of the input to H when done by an actual pure simulator/UTM?
>>>>>>>
>>>>>> As long as it is done at the exact point in the execution trace as
>>>>>> H(P,P) then it is fine, otherwise it is not the same as the
>>>>>> simulation by H(P,P).
>>>>>>
>>>>>
>>>>> The simulation of the input to H(P,P) is the simulation of the
>>>>> instruction sequence specified by the code of P (and the routines
>>>>> it calls) and has ZERO dependency on what happened before that call
>>>>
>>>> main()
>>>> {
>>>>    P(P); // depends on the return value from H(P,P);
>>>> }
>>>>
>>>> The input to H(P,P) that H correctly simulates cannot possibly
>>>> depend on the return value from H because this return value is
>>>> unreachable by P:
>>>
>>> But it NEEDS to. That fact that it can't get the needed value because
>>> of the limitation of your algorithm, doesn't mean it gets to ignore it.
>>>
>>> Not, Mr Flibble has shown a way that H CAN determine the behavior of
>>> P based on the return value of H, even though H can simulate the path
>>> through itself.
>>>
>>> (As I pointed out a long time ago too).
>>
>> Every function that is called in infinite recursion cannot possibly
>> correctly return to its caller. People that believe that it can are as
>> wrong as if they disagreed with arithmetic.
>>
>> If computer science says that a function called in finite recursion
>> must return to its caller then computer science is wrong, one might as
>> well have said the cats must be dogs.
>>
>>>>
>>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>>>> (b) that simulates P(P) that calls a simulated H(P,P)
>>>> (c) that simulates P(P) that calls a simulated H(P,P)
>>>> (d) that simulates P(P) that calls a simulated H(P,P)...
>>>> *Until H aborts its simulation*
>>>>
>>>> This dependency difference causes the different behavior between the
>>>> simulated P and the executed P.
>>>
>>> Nope, the CORRECT AND COMPLETE simulation of the input does depend on
>>> the value that H(P,P) returns, unless H(P,P) never returns a value to
>>> ANYBODY.
>>>
>>> Your H just gets it wrong because it "guesses" wrong because it used
>>> unsound logic.
>>>
>>
>> You know that it did not merely guess.
>> You know that the correct and complete simulation by H(P,P) of its
>> input would never reach the final state of this input.
>
> No, that is a MEANINGLESS statement, because you H doesn't DO a complete
> simulation.
>

On 8/22/22 11:11 AM, olcott wrote:
> On 8/22/2022 9:55 AM, Mikko wrote:
>> On 2022-08-22 14:25:13 +0000, olcott said:
>>
>>> The question is always:
>>> Would the input simulated by H reach the final state of this input if
>>> H never aborts its simulation of this input?
>>
>> That is your qestion. The halting problem's question is "Does the Turing
>> machine T halt when given the input I?" and the problem itself is whether
>> there is a Turing machine that can always correctly answer that question.
>>
>
> *The generic form of the question is*
> Does the finite string input specific a sequence of instruction that
> reach their own final state?
>
> It is common knowledge that the correct and complete simulation of a
> machine description always provides the actual behavior specified by
> this machine description.
>
> The correct and complete simulation by H(P,P) of its input would never
> reach its final state and halt, thus the input to H(P,P) specifies a
> non-halting sequence of instructions.
>
>>> This means that the standard definition of the halting function IS
>>> WRONG because it directly contradicts other correct definitions.
>>
>> The definition is not wrong. You can avoid all problem in the definition
>> by avoiding any use of the term "halting function". There are other
>> words you can use instead.
>>
>> Mikko
>>
>
> The standard definition of the halting function sometimes requires the
> halt status decision to be based on something other than the actual
> behavior of the actual input, and in those cases IT IS WRONG!

Nope, the ACTUAL BEHAVIOR of the input, since it is a Halt Decider, is
what a UTM (or a pure simulation) would do applied to that input.

it is NOT based on a partial simulation that the decider does.

FAIL.

>
> int sum(int x, int y)
> {
>   return x + y;
> }
>
> If sum(3,4) returned the sum of 5 + 7 we would know that it is wrong.
> Likewise H(P,P) cannot be based on the behavior of the directly executed
> P(P).

WRONG, you are just showing your ignorance.

Now, yes, it turns out that it is actually impossible for H to determine
that actual behavior of this input, but that isn't because the problem
is defined wrong, but because the problem just turns out to be
non-computable.
>
> main()
> {
>   P(P); // depends on the return value from H(P,P);
> }
>
> The input to H(P,P) that H correctly simulates cannot possibly depend on
> the return value from H because this return value is unreachable by P:
>

Nope, you logic is wrong.

> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
> (b) that simulates P(P) that calls a simulated H(P,P)
> (c) that simulates P(P) that calls a simulated H(P,P)
> (d) that simulates P(P) that calls a simulated H(P,P)...
> *Until H aborts its simulation*
>
> This dependency difference causes the different behavior between the
> simulated P and the executed P.
>
>
>

Nope. Just wrong logic.

We don't CARE that H can't simulate the input to the final state, we
care if the input simulated by a UTM reaches the final state, which is
exactly the same (by definition) as the direct execution of the input.

All your arguement that this is impossible are just AGREEING with the
Halting Theorem, that the Halting FUnction is NOT Computable.

On 8/22/22 7:33 PM, olcott wrote:
> On 8/22/2022 6:21 PM, Richard Damon wrote:
>> On 8/22/22 10:31 AM, olcott wrote:
>>> On 8/21/2022 10:37 PM, Richard Damon wrote:
>>>> On 8/21/22 11:27 PM, olcott wrote:
>>>>> On 8/21/2022 10:14 PM, Richard Damon wrote:
>>>>>> On 8/21/22 9:37 PM, olcott wrote:
>>>>>>> On 8/21/2022 8:04 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> On 8/21/22 8:45 PM, olcott wrote:
>>>>>>>>> On 8/21/2022 1:04 PM, Richard Damon wrote:
>>>>>>>>>> On 8/21/22 11:36 AM, olcott wrote:
>>>>>>>>>>> On 8/21/2022 10:16 AM, Shvili, the Kookologist wrote:
>>>>>>>>>>>> On Sat, 20 Aug 2022 16:01:31 -0500, in article
>>>>>>>>>>>> <crudnRbncP4E1pz-
>>>>>>>>>>>> nZ2dnZfqlJzNnZ2d@giganews.com>, olcott wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> [snip]
>>>>>>>>>>>>
>>>>>>>>>>>>> It is common knowledge that [...]
>>>>>>>>>>>>
>>>>>>>>>>>> Have you noticed that almost every time you use this phrase,
>>>>>>>>>>>> you're
>>>>>>>>>>>> wrong?
>>>>>>>>>>>> So also this time.
>>>>>>>>>>>>
>>>>>>>>>>>>> [...] the correct and complete simulation of a
>>>>>>>>>>>>> machine description [...]
>>>>>>>>>>>>
>>>>>>>>>>>> Machine descriptions are never simulated -- they're just
>>>>>>>>>>>> sequences
>>>>>>>>>>>> of symbols.
>>>>>>>>>>>> and don't have any defined behaviour. The machines they
>>>>>>>>>>>> *represent*
>>>>>>>>>>>> may be
>>>>>>>>>>>> simulated.
>>>>>>>>>>>>
>>>>>>>>>>>>> [...] always provides the actual behavior specified by
>>>>>>>>>>>>> this machine description.
>>>>>>>>>>>>
>>>>>>>>>>>> This is almost, but not quite, correct (if you fix it
>>>>>>>>>>>> according to
>>>>>>>>>>>> the
>>>>>>>>>>>> previous paragraph). It would have been completely correct,
>>>>>>>>>>>> if it
>>>>>>>>>>>> weren't
>>>>>>>>>>>> for the fact that you're using an utterly bizarre meaning
>>>>>>>>>>>> for the
>>>>>>>>>>>> phrase
>>>>>>>>>>>> "the actual behavior specified by this machine description".
>>>>>>>>>>>>
>>>>>>>>>>>>> That you and others reject this when it is applied to my
>>>>>>>>>>>>> simulating halt
>>>>>>>>>>>>> decider implicitly rejects the notion of a UTM. Since you
>>>>>>>>>>>>> and others do
>>>>>>>>>>>>> accept the notion of a UTM, I have just proven that your
>>>>>>>>>>>>> reasoning is
>>>>>>>>>>>>> incoherent and/or inconsistent.
>>>>>>>>>>>>
>>>>>>>>>>>> Let M be a given machine, with machine description [M], and
>>>>>>>>>>>> let w
>>>>>>>>>>>> be
>>>>>>>>>>>> a given input tape, with tape description [w]. Then the
>>>>>>>>>>>> "simulation"
>>>>>>>>>>>> UTM([M],[w]) has exactly the same result (i.e. exactly the same
>>>>>>>>>>>> behaviour)
>>>>>>>>>>>> as the direct computation M(w). This is actually the
>>>>>>>>>>>> definition of
>>>>>>>>>>>> a UTM.
>>>>>>>>>>>>
>>>>>>>>>>>> Another way of expressing this is: M(w) and UTM([M],[w])
>>>>>>>>>>>> compute
>>>>>>>>>>>> the same
>>>>>>>>>>>> partial function.
>>>>>>>>>>>>
>>>>>>>>>>>> You have made it abundantly clear that when you say "the actual
>>>>>>>>>>>> behavior
>>>>>>>>>>>> specified by this machine description", you do *not* mean "the
>>>>>>>>>>>> actual
>>>>>>>>>>>> behavior specified by this machine description", because that's
>>>>>>>>>>>> simply
>>>>>>>>>>>> the behaviour of M(w). What you *do* mean is "the behaviour
>>>>>>>>>>>> of your
>>>>>>>>>>>> particular, broken and incomplete, quasi-simulation based on
>>>>>>>>>>>> [M]
>>>>>>>>>>>> and [w]".
>>>>>>>>>>>>
>>>>>>>>>>>> Why is it broken? Because it *doesn't* have the same
>>>>>>>>>>>> behaviour as M
>>>>>>>>>>>> (w),
>>>>>>>>>>>> nor as UTM([M],[w]). A correct simulation *means* that it
>>>>>>>>>>>> has the
>>>>>>>>>>>> same
>>>>>>>>>>>> behaviour as M(w).
>>>>>>>>>>>>
>>>>>>>>>>>> Why is it incomplete? Because it aborts its "simulation"
>>>>>>>>>>>> before it
>>>>>>>>>>>> reaches
>>>>>>>>>>>> a halting configuration of the machine represented by its
>>>>>>>>>>>> input,
>>>>>>>>>>>> and it
>>>>>>>>>>>> does so on invalidly.
>>>>>>>>>>>>
>>>>>>>>>>>> Why is it a quasi-simulation? Because it depends on external
>>>>>>>>>>>> input
>>>>>>>>>>>> that is
>>>>>>>>>>>> contained in neither [M] nor [w]. You have said, on numerous
>>>>>>>>>>>> occasions,
>>>>>>>>>>>> that the behaviour of your "H(P,P)" depends on the specific
>>>>>>>>>>>> memory
>>>>>>>>>>>> location of "P". Well, then that location is an external input.
>>>>>>>>>>>> Your H is
>>>>>>>>>>>> *not* analogous to Linz' H([M],[w]).
>>>>>>>>>>>>
>>>>>>>>>>>> This is the point where you usually barf up your stanza
>>>>>>>>>>>> about how
>>>>>>>>>>>> the
>>>>>>>>>>>> behaviour of your "H(P,P)" cannot be expected to be computed
>>>>>>>>>>>> "from
>>>>>>>>>>>> the
>>>>>>>>>>>> non-input P(P)". This is obviously idiotic, for the following
>>>>>>>>>>>> reasons:
>>>>>>>>>>>>
>>>>>>>>>>>> 1) A purported halt decider H([M],[w]) is *not* required to
>>>>>>>>>>>> compute
>>>>>>>>>>>> its
>>>>>>>>>>>>     result *from* M(w), but to *match* M(w). Computing
>>>>>>>>>>>> *from* M(w)
>>>>>>>>>>>> would be
>>>>>>>>>>>>     completely pointless, because the decider would already
>>>>>>>>>>>> know the
>>>>>>>>>>>> answer.
>>>>>>>>>>>>
>>>>>>>>>>>>     Since you seem unable to understand anything but
>>>>>>>>>>>> arguments from
>>>>>>>>>>>>     analogy, let me re-use one that you yourself have employed:
>>>>>>>>>>>> Suppose
>>>>>>>>>>>>     we want to construct an addition algorithm add(x,y). If
>>>>>>>>>>>> you were
>>>>>>>>>>>> to
>>>>>>>>>>>>     complain that add(5,7) cannot be required to compute its
>>>>>>>>>>>> result
>>>>>>>>>>>> "from
>>>>>>>>>>>>     the non-input 12", you would, quite rightly, be regarded
>>>>>>>>>>>> as a
>>>>>>>>>>>> complete
>>>>>>>>>>>>     nitwit. Can you now guess why you're universally
>>>>>>>>>>>> regarded as a
>>>>>>>>>>>> complete
>>>>>>>>>>>>     nitwit?
>>>>>>>>>>>>
>>>>>>>>>>>> 2) The behaviour of UTM([M],[w]) is *defined* to match the
>>>>>>>>>>>> behaviour of M(w),
>>>>>>>>>>>>     and UTMs very evidently do exist. The information
>>>>>>>>>>>> contained in
>>>>>>>>>>>> [M] and [w]
>>>>>>>>>>>>     is obviously enough to match the behaviour of M(w). The
>>>>>>>>>>>> fact
>>>>>>>>>>>> that your
>>>>>>>>>>>>     "simulator" fails in this regard, is proof that your
>>>>>>>>>>>> "simulator" is
>>>>>>>>>>>>     defective -- *not* that you have discovered a "loop
>>>>>>>>>>>> hole", or
>>>>>>>>>>>> that halting
>>>>>>>>>>>>     theorem is faulty, or anything of that kind -- only that
>>>>>>>>>>>> you're
>>>>>>>>>>>> working
>>>>>>>>>>>>     with a broken simulator.
>>>>>>>>>>>>
>>>>>>>>>>>>> *NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE THERE IS
>>>>>>>>>>>>> NO ERROR*
>>>>>>>>>>>>
>>>>>>>>>>>> A lot of people have pointed out many kinds of errors in your
>>>>>>>>>>>> reasoning.
>>>>>>>>>>>> You usually respond with some form "proof by regurgitation". I
>>>>>>>>>>>> expect you
>>>>>>>>>>>> will do so to this post.
>>>>>>>>>>>>
>>>>>>>>>>>>> When-so-ever a simulating halt decider (SHD) correctly
>>>>>>>>>>>>> performs a
>>>>>>>>>>>>> partial simulation of its input and the behavior of this
>>>>>>>>>>>>> partial
>>>>>>>>>>>>> simulation correctly matches a non-halting behavior pattern
>>>>>>>>>>>>> then the SHD
>>>>>>>>>>>>> halt decider can correctly report non-halting.
>>>>>>>>>>>>>
>>>>>>>>>>>>> A non-halting behavior pattern is correct when-so-ever
>>>>>>>>>>>>> matching this
>>>>>>>>>>>>> behavior pattern proves that the correct and complete
>>>>>>>>>>>>> simulation of the
>>>>>>>>>>>>> input by SHD would never reach the final state of this
>>>>>>>>>>>>> simulated input.
>>>>>>>>>>>>
>>>>>>>>>>>> Yeah, that's just a bunch of equivocations on "correctly", "its
>>>>>>>>>>>> input",
>>>>>>>>>>>> "non-halting behavior", and more.  Please learn to write
>>>>>>>>>>>> clearly.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Also, could you *please* stop misreading Linz! He *doesn't* say
>>>>>>>>>>>> that a TM
>>>>>>>>>>>> halts, only if it enters a "final state". What he actually
>>>>>>>>>>>> says is:
>>>>>>>>>>>>
>>>>>>>>>>>>      "A Turing machine is said to halt whenever it reaches a
>>>>>>>>>>>> configuration
>>>>>>>>>>>>      for which delta is not defined; this is possible
>>>>>>>>>>>> because delta
>>>>>>>>>>>> is a
>>>>>>>>>>>>      partial function. In fact, we will assume that no
>>>>>>>>>>>> transitions
>>>>>>>>>>>> are
>>>>>>>>>>>>      defined for any final state, so the Turing machine will
>>>>>>>>>>>> halt
>>>>>>>>>>>> whenever
>>>>>>>>>>>>      it enters a final state."
>>>>>>>>>>>>
>>>>>>>>>>>> So, for a general TM, there may well be configurations for
>>>>>>>>>>>> which
>>>>>>>>>>>> the TM
>>>>>>>>>>>> halts in a non-final state. It is, on the other hand,
>>>>>>>>>>>> understood
>>>>>>>>>>>> that a TM
>>>>>>>>>>>> *only* stops running if enters a configuration for which the
>>>>>>>>>>>> transition
>>>>>>>>>>>> function is undefined.
>>>>>>>>>>>>
>>>>>>>>>>>> "Final states" only concern the *interpretation* of the
>>>>>>>>>>>> value of a
>>>>>>>>>>>> computation -- *not* whether the TM halts or not.
>>>>>>>>>>>>
>>>>>>>>>>>> This means that "halting" and "stops running" are the exact the
>>>>>>>>>>>> same things.
>>>>>>>>>>>> And obviously, "running" and "being simulated" are two entirely
>>>>>>>>>>>> different
>>>>>>>>>>>> things.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>> {
>>>>>>>>>>>    int Halt_Status = UTM(x, x);
>>>>>>>>>>>    if (Halt_Status)
>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>    return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> The behavior of the actual input to the simulating halt
>>>>>>>>>>> decider is the behavior of the above. Since C functions do
>>>>>>>>>>> not actually have UTM's a more accurate way of sayoing this is:
>>>>>>>>>>>
>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>> {
>>>>>>>>>>>    int Halt_Status = Simulate(x, x);
>>>>>>>>>>>    if (Halt_Status)
>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>    return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> The behavior of UTM(P,P) or Simulate(P,P) is not the behavior
>>>>>>>>>>> of the actual input to H(P,P) because it is at a different
>>>>>>>>>>> point in the execution trace than H(P,P).
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Wrong, at least if H is supposed to be a Halt Decider.
>>>>>>>>>>
>>>>>>>>>> You forget the question that the Halt Decider is being asked
>>>>>>>>>> to solve, which is what the machine represented by its input
>>>>>>>>>> would do.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It is common knowledge that the correct and complete simulation
>>>>>>>>> of a machine description always provides the actual behavior
>>>>>>>>> specified by this machine description.
>>>>>>>>
>>>>>>>> Right.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> That you (and others such as Ben) reject that the correct and
>>>>>>>>> complete simulation by H(P,P) of its input does provide the
>>>>>>>>> actual behavior of this input also rejects the notion of a UTM
>>>>>>>>> which you accept, thus you (and all others holding this view
>>>>>>>>> such as Ben) contradict yourself (themselves).
>>>>>>>>>
>>>>>>>>
>>>>>>>> So, why do you reject the actual correct and complete simulation
>>>>>>>> of the input to H when done by an actual pure simulator/UTM?
>>>>>>>>
>>>>>>> As long as it is done at the exact point in the execution trace
>>>>>>> as H(P,P) then it is fine, otherwise it is not the same as the
>>>>>>> simulation by H(P,P).
>>>>>>>
>>>>>>
>>>>>> The simulation of the input to H(P,P) is the simulation of the
>>>>>> instruction sequence specified by the code of P (and the routines
>>>>>> it calls) and has ZERO dependency on what happened before that call
>>>>>
>>>>> main()
>>>>> {
>>>>>    P(P); // depends on the return value from H(P,P);
>>>>> }
>>>>>
>>>>> The input to H(P,P) that H correctly simulates cannot possibly
>>>>> depend on the return value from H because this return value is
>>>>> unreachable by P:
>>>>
>>>> But it NEEDS to. That fact that it can't get the needed value
>>>> because of the limitation of your algorithm, doesn't mean it gets to
>>>> ignore it.
>>>>
>>>> Not, Mr Flibble has shown a way that H CAN determine the behavior of
>>>> P based on the return value of H, even though H can simulate the
>>>> path through itself.
>>>>
>>>> (As I pointed out a long time ago too).
>>>
>>> Every function that is called in infinite recursion cannot possibly
>>> correctly return to its caller. People that believe that it can are
>>> as wrong as if they disagreed with arithmetic.
>>>
>>> If computer science says that a function called in finite recursion
>>> must return to its caller then computer science is wrong, one might
>>> as well have said the cats must be dogs.
>>>
>>>>>
>>>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>>>>> (b) that simulates P(P) that calls a simulated H(P,P)
>>>>> (c) that simulates P(P) that calls a simulated H(P,P)
>>>>> (d) that simulates P(P) that calls a simulated H(P,P)...
>>>>> *Until H aborts its simulation*
>>>>>
>>>>> This dependency difference causes the different behavior between
>>>>> the simulated P and the executed P.
>>>>
>>>> Nope, the CORRECT AND COMPLETE simulation of the input does depend
>>>> on the value that H(P,P) returns, unless H(P,P) never returns a
>>>> value to ANYBODY.
>>>>
>>>> Your H just gets it wrong because it "guesses" wrong because it used
>>>> unsound logic.
>>>>
>>>
>>> You know that it did not merely guess.
>>> You know that the correct and complete simulation by H(P,P) of its
>>> input would never reach the final state of this input.
>>
>> No, that is a MEANINGLESS statement, because you H doesn't DO a
>> complete simulation.
>>
>
>
> Do you know how ridiculously stupid it is of you of you to suggest that
> a simulating halt decider perform a complete simulation of its
> non-halting input?

On 8/22/2022 6:30 PM, Richard Damon wrote:
>
> On 8/22/22 10:25 AM, olcott wrote:
>> On 8/21/2022 10:24 PM, Richard Damon wrote:
>>> On 8/21/22 9:44 PM, olcott wrote:
>>>> On 8/21/2022 8:12 PM, Richard Damon wrote:
>>>>>
>>>>> On 8/21/22 8:48 PM, olcott wrote:
>>>>>> On 8/21/2022 1:09 PM, Richard Damon wrote:
>>>>>>> On 8/21/22 9:30 AM, olcott wrote:
>>>>>>>> On 8/21/2022 4:00 AM, Mikko wrote:
>>>>>>>>> On 2022-08-20 15:01:34 +0000, Fred. Zwarts said:
>>>>>>>>>
>>>>>>>>>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>>>>>>>>>> Olcott, which of the following do you think is more likely?
>>>>>>>>>>>
>>>>>>>>>>> 1) Olcott is correct and everybody else is wrong.
>>>>>>>>>>> 2) Olcott is wrong and everybody else is correct.
>>>>>>>>>>>
>>>>>>>>>>> Which one is more likely hasn't changed for all the years
>>>>>>>>>>> you've been
>>>>>>>>>>> attempting to shill your simulating halting decider.  I find
>>>>>>>>>>> it amusing
>>>>>>>>>>> that I came up with, in less than 24 hours, a simulating halting
>>>>>>>>>>> decider that doesn't have the flaws your SHD has.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I have been following these discussions for many months now. I
>>>>>>>>>> have a strong impression that there is little progress. It
>>>>>>>>>> seems that people are running in circles. I am not an expert
>>>>>>>>>> in this field. Maybe it helps if a non-expert tries to
>>>>>>>>>> summarize the discussion. Please, be patient when correcting
>>>>>>>>>> me if I make any mistake.
>>>>>>>>>>
>>>>>>>>>> First the problem this is al about:
>>>>>>>>>> In computation theory we can denote a program with X and its
>>>>>>>>>> input with Y, which together is denoted as X(Y). X(Y) may end
>>>>>>>>>> (halt) in a finite number of steps, but another program X
>>>>>>>>>> and/or input Y may not halt in a finite number of steps. The
>>>>>>>>>> question is, is it possible to create a program H that when
>>>>>>>>>> given any program X with its input Y can tell in a finite
>>>>>>>>>> number of steps whether X(Y) halts or not? In other words,
>>>>>>>>>> will H(X,Y) always halt after a finite number of steps with
>>>>>>>>>> the correct answer for any X and Y?
>>>>>>>>>
>>>>>>>>> In the classical formulation X and H are Turing machines. Y is
>>>>>>>>> a finite
>>>>>>>>> string of symbols from some finite set. H(X,Y) denotes a
>>>>>>>>> computation where
>>>>>>>>> H is given a finite string that represents X and Y so that each
>>>>>>>>> can be
>>>>>>>>> reconstructed.
>>>>>>>>>
>>>>>>>>>> I hope that this is a correct formulation of the problem.
>>>>>>>>>>
>>>>>>>>>> The classical proof that it is not possible is the idea that
>>>>>>>>>> it is always possible to create a program P that uses H, with
>>>>>>>>>> itself as input, but behaves opposite to what H returns. In a
>>>>>>>>>> C-like language it would be something like:
>>>>>>>>>>
>>>>>>>>>> void P(ptr x)
>>>>>>>>>> {
>>>>>>>>>>    int Halt_Status = H(x, x);
>>>>>>>>>>    if (Halt_Status)
>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>    return;
>>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Roughly so but both P and H take a single string as argument:
>>>>>>>>>
>>>>>>>>> void P(string x)
>>>>>>>>> {
>>>>>>>>>   string arg = pair(x, x);
>>>>>>>>>   boolean Halt_Status = H(arg);
>>>>>>>>>   if (Halt_Status)
>>>>>>>>>     HERE: goto HERE;
>>>>>>>>>   return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>> If there would be a hypothetical non-simulating non-aborting
>>>>>>>>>> H, which would always halts with the correct answer, then it
>>>>>>>>>> is clear that there would be a contradiction if we ask H about
>>>>>>>>>> P with H(P,P). Because there are only three possibilities:
>>>>>>>>>> 1. If H would return true (halting) in a finite number of
>>>>>>>>>> steps, then P would start an endless loop, so H(P,P) does not
>>>>>>>>>> halt in a finite number of steps.
>>>>>>>>>> 2. If H would return false (non-halting) in a finite number of
>>>>>>>>>> steps, then P returns immediately, so H returns a wrong result.
>>>>>>>>>> 3. If H does not return, then it does not return in a finite
>>>>>>>>>> number of steps, so it is not the H where the problem asked for.
>>>>>>>>>
>>>>>>>>> With Turing machines the possibilities are:
>>>>>>>>> 1. H halts with the answer true.
>>>>>>>>> 2. H halts with the answer false.
>>>>>>>>> 3. H halts but answers neither true nor false.
>>>>>>>>> 4. H does not halt.
>>>>>>>>>
>>>>>>>>> If 3 or 4 happens then H is not a halt decider, i.e., not a
>>>>>>>>> solution
>>>>>>>>> to the problem. If H(P, P) halts with the answer true then P(P)
>>>>>>>>> does
>>>>>>>>> not halt so H is not a halt decider. If H(P, P) halts with the
>>>>>>>>> answer false then P(P) halts so H is not a halt decider.
>>>>>>>>>
>>>>>>>>> The restriction to non-simulating non-aborting H is not necessary.
>>>>>>>>> The requirements are the same anyway.
>>>>>>>>>
>>>>>>>>>> I think everybody agrees up to this point.
>>>>>>>>>>
>>>>>>>>>> Now Olcott has created a simulating aborting H, which, when
>>>>>>>>>> given P with input P [so H(P,P)], creates a trace of the
>>>>>>>>>> execution and at the point where P calls H, it uses the
>>>>>>>>>> following logic: If H were the hypothetical non-aborting H,
>>>>>>>>>> then an infinite recursion would happen at this point.
>>>>>>>>>> Therefore, Olcott's simulating H aborts the simulation and
>>>>>>>>>> returns false (0).
>>>>>>>>>>
>>>>>>>>>> Does everybody still agree up to this point?
>>>>>>>>>
>>>>>>>>> Yes, and everybody also agrees that P(P) halts.
>>>>>>>>>
>>>>>>>>
>>>>>>>> It is common knowledge that the correct and complete simulation
>>>>>>>> of a machine description always provides the actual behavior
>>>>>>>> specified by this machine description.
>>>>>>>>
>>>>>>>> The correct and complete simulation by H(P,P) of its input would
>>>>>>>> never reach its final state and halt, thus the input to H(P,P)
>>>>>>>> specifies a non-halting sequence of instructions.
>>>>>>
>>>>>>> Which might make some sense, until we notice that the only H that
>>>>>>> actually does a correct and complete simulation of its input, is
>>>>>>> the H that doesn't abort its simulation and thus never answers so
>>>>>>> fails to be a Halt Decider.
>>>>>> *YOU JUST AREN'T BRIGHT ENOUGH TO COMPREHEND THIS*
>>>>>> When-so-ever a simulating halt decider (SHD) correctly performs a
>>>>>> partial simulation of its input and the behavior of this partial
>>>>>> simulation correctly matches a non-halting behavior pattern then
>>>>>> the SHD halt decider can correctly report non-halting.
>>>>>
>>>>> What is the CORRECT non-halting pattern that the simulation of P(P)
>>>>> correctly matched.
>>>>>
>>>>
>>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>>>> (b) that simulates P(P) that calls a simulated H(P,P)
>>>> (c) that simulates P(P) that calls a simulated H(P,P)
>>>> (d) that simulates P(P) that calls a simulated H(P,P)...
>>>> *Until H aborts its simulation*
>>>>
>>>>
>>>
>>> Which isn't a correct non-halting pattern if H ever actually get to
>>> the abort,
>>
>>
>> The question is always:
>> Would the input simulated by H reach the final state of this input if
>> H never aborts its simulation of this input?
>
> So your back to POOP"?
>
> The Halting Question has ALWAYS been, does the machine represented by
> the input Halt when given the input specified.
>
This is contradicted by the fact that a halt decider must base its halt
status decision on the actual behavior of the actual input and cannot
correctly base it on anything else.

On 8/22/22 8:08 PM, olcott wrote:
> On 8/22/2022 6:30 PM, Richard Damon wrote:
>>
>> On 8/22/22 10:25 AM, olcott wrote:
>>> On 8/21/2022 10:24 PM, Richard Damon wrote:
>>>> On 8/21/22 9:44 PM, olcott wrote:
>>>>> On 8/21/2022 8:12 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 8/21/22 8:48 PM, olcott wrote:
>>>>>>> On 8/21/2022 1:09 PM, Richard Damon wrote:
>>>>>>>> On 8/21/22 9:30 AM, olcott wrote:
>>>>>>>>> On 8/21/2022 4:00 AM, Mikko wrote:
>>>>>>>>>> On 2022-08-20 15:01:34 +0000, Fred. Zwarts said:
>>>>>>>>>>
>>>>>>>>>>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>>>>>>>>>>> Olcott, which of the following do you think is more likely?
>>>>>>>>>>>>
>>>>>>>>>>>> 1) Olcott is correct and everybody else is wrong.
>>>>>>>>>>>> 2) Olcott is wrong and everybody else is correct.
>>>>>>>>>>>>
>>>>>>>>>>>> Which one is more likely hasn't changed for all the years
>>>>>>>>>>>> you've been
>>>>>>>>>>>> attempting to shill your simulating halting decider.  I find
>>>>>>>>>>>> it amusing
>>>>>>>>>>>> that I came up with, in less than 24 hours, a simulating
>>>>>>>>>>>> halting
>>>>>>>>>>>> decider that doesn't have the flaws your SHD has.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I have been following these discussions for many months now.
>>>>>>>>>>> I have a strong impression that there is little progress. It
>>>>>>>>>>> seems that people are running in circles. I am not an expert
>>>>>>>>>>> in this field. Maybe it helps if a non-expert tries to
>>>>>>>>>>> summarize the discussion. Please, be patient when correcting
>>>>>>>>>>> me if I make any mistake.
>>>>>>>>>>>
>>>>>>>>>>> First the problem this is al about:
>>>>>>>>>>> In computation theory we can denote a program with X and its
>>>>>>>>>>> input with Y, which together is denoted as X(Y). X(Y) may end
>>>>>>>>>>> (halt) in a finite number of steps, but another program X
>>>>>>>>>>> and/or input Y may not halt in a finite number of steps. The
>>>>>>>>>>> question is, is it possible to create a program H that when
>>>>>>>>>>> given any program X with its input Y can tell in a finite
>>>>>>>>>>> number of steps whether X(Y) halts or not? In other words,
>>>>>>>>>>> will H(X,Y) always halt after a finite number of steps with
>>>>>>>>>>> the correct answer for any X and Y?
>>>>>>>>>>
>>>>>>>>>> In the classical formulation X and H are Turing machines. Y is
>>>>>>>>>> a finite
>>>>>>>>>> string of symbols from some finite set. H(X,Y) denotes a
>>>>>>>>>> computation where
>>>>>>>>>> H is given a finite string that represents X and Y so that
>>>>>>>>>> each can be
>>>>>>>>>> reconstructed.
>>>>>>>>>>
>>>>>>>>>>> I hope that this is a correct formulation of the problem.
>>>>>>>>>>>
>>>>>>>>>>> The classical proof that it is not possible is the idea that
>>>>>>>>>>> it is always possible to create a program P that uses H, with
>>>>>>>>>>> itself as input, but behaves opposite to what H returns. In a
>>>>>>>>>>> C-like language it would be something like:
>>>>>>>>>>>
>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>> {
>>>>>>>>>>>    int Halt_Status = H(x, x);
>>>>>>>>>>>    if (Halt_Status)
>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>    return;
>>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> Roughly so but both P and H take a single string as argument:
>>>>>>>>>>
>>>>>>>>>> void P(string x)
>>>>>>>>>> {
>>>>>>>>>>   string arg = pair(x, x);
>>>>>>>>>>   boolean Halt_Status = H(arg);
>>>>>>>>>>   if (Halt_Status)
>>>>>>>>>>     HERE: goto HERE;
>>>>>>>>>>   return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>>> If there would be a hypothetical non-simulating non-aborting
>>>>>>>>>>> H, which would always halts with the correct answer, then it
>>>>>>>>>>> is clear that there would be a contradiction if we ask H
>>>>>>>>>>> about P with H(P,P). Because there are only three possibilities:
>>>>>>>>>>> 1. If H would return true (halting) in a finite number of
>>>>>>>>>>> steps, then P would start an endless loop, so H(P,P) does not
>>>>>>>>>>> halt in a finite number of steps.
>>>>>>>>>>> 2. If H would return false (non-halting) in a finite number
>>>>>>>>>>> of steps, then P returns immediately, so H returns a wrong
>>>>>>>>>>> result.
>>>>>>>>>>> 3. If H does not return, then it does not return in a finite
>>>>>>>>>>> number of steps, so it is not the H where the problem asked for.
>>>>>>>>>>
>>>>>>>>>> With Turing machines the possibilities are:
>>>>>>>>>> 1. H halts with the answer true.
>>>>>>>>>> 2. H halts with the answer false.
>>>>>>>>>> 3. H halts but answers neither true nor false.
>>>>>>>>>> 4. H does not halt.
>>>>>>>>>>
>>>>>>>>>> If 3 or 4 happens then H is not a halt decider, i.e., not a
>>>>>>>>>> solution
>>>>>>>>>> to the problem. If H(P, P) halts with the answer true then
>>>>>>>>>> P(P) does
>>>>>>>>>> not halt so H is not a halt decider. If H(P, P) halts with the
>>>>>>>>>> answer false then P(P) halts so H is not a halt decider.
>>>>>>>>>>
>>>>>>>>>> The restriction to non-simulating non-aborting H is not
>>>>>>>>>> necessary.
>>>>>>>>>> The requirements are the same anyway.
>>>>>>>>>>
>>>>>>>>>>> I think everybody agrees up to this point.
>>>>>>>>>>>
>>>>>>>>>>> Now Olcott has created a simulating aborting H, which, when
>>>>>>>>>>> given P with input P [so H(P,P)], creates a trace of the
>>>>>>>>>>> execution and at the point where P calls H, it uses the
>>>>>>>>>>> following logic: If H were the hypothetical non-aborting H,
>>>>>>>>>>> then an infinite recursion would happen at this point.
>>>>>>>>>>> Therefore, Olcott's simulating H aborts the simulation and
>>>>>>>>>>> returns false (0).
>>>>>>>>>>>
>>>>>>>>>>> Does everybody still agree up to this point?
>>>>>>>>>>
>>>>>>>>>> Yes, and everybody also agrees that P(P) halts.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It is common knowledge that the correct and complete simulation
>>>>>>>>> of a machine description always provides the actual behavior
>>>>>>>>> specified by this machine description.
>>>>>>>>>
>>>>>>>>> The correct and complete simulation by H(P,P) of its input
>>>>>>>>> would never reach its final state and halt, thus the input to
>>>>>>>>> H(P,P) specifies a non-halting sequence of instructions.
>>>>>>>
>>>>>>>> Which might make some sense, until we notice that the only H
>>>>>>>> that actually does a correct and complete simulation of its
>>>>>>>> input, is the H that doesn't abort its simulation and thus never
>>>>>>>> answers so fails to be a Halt Decider.
>>>>>>> *YOU JUST AREN'T BRIGHT ENOUGH TO COMPREHEND THIS*
>>>>>>> When-so-ever a simulating halt decider (SHD) correctly performs a
>>>>>>> partial simulation of its input and the behavior of this partial
>>>>>>> simulation correctly matches a non-halting behavior pattern then
>>>>>>> the SHD halt decider can correctly report non-halting.
>>>>>>
>>>>>> What is the CORRECT non-halting pattern that the simulation of
>>>>>> P(P) correctly matched.
>>>>>>
>>>>>
>>>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>>>>> (b) that simulates P(P) that calls a simulated H(P,P)
>>>>> (c) that simulates P(P) that calls a simulated H(P,P)
>>>>> (d) that simulates P(P) that calls a simulated H(P,P)...
>>>>> *Until H aborts its simulation*
>>>>>
>>>>>
>>>>
>>>> Which isn't a correct non-halting pattern if H ever actually get to
>>>> the abort,
>>>
>>>
>>> The question is always:
>>> Would the input simulated by H reach the final state of this input if
>>> H never aborts its simulation of this input?
>>
>> So your back to POOP"?
>>
>> The Halting Question has ALWAYS been, does the machine represented by
>> the input Halt when given the input specified.
>>
> This is contradicted by the fact that a halt decider must base its halt
> status decision on the actual behavior of the actual input and cannot
> correctly base it on anything else.

On 8/22/2022 6:58 PM, Richard Damon wrote:
> On 8/22/22 7:33 PM, olcott wrote:
>> On 8/22/2022 6:21 PM, Richard Damon wrote:
>>> On 8/22/22 10:31 AM, olcott wrote:
>>>> On 8/21/2022 10:37 PM, Richard Damon wrote:
>>>>> On 8/21/22 11:27 PM, olcott wrote:
>>>>>> On 8/21/2022 10:14 PM, Richard Damon wrote:
>>>>>>> On 8/21/22 9:37 PM, olcott wrote:
>>>>>>>> On 8/21/2022 8:04 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 8/21/22 8:45 PM, olcott wrote:
>>>>>>>>>> On 8/21/2022 1:04 PM, Richard Damon wrote:
>>>>>>>>>>> On 8/21/22 11:36 AM, olcott wrote:
>>>>>>>>>>>> On 8/21/2022 10:16 AM, Shvili, the Kookologist wrote:
>>>>>>>>>>>>> On Sat, 20 Aug 2022 16:01:31 -0500, in article
>>>>>>>>>>>>> <crudnRbncP4E1pz-
>>>>>>>>>>>>> nZ2dnZfqlJzNnZ2d@giganews.com>, olcott wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> [snip]
>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is common knowledge that [...]
>>>>>>>>>>>>>
>>>>>>>>>>>>> Have you noticed that almost every time you use this
>>>>>>>>>>>>> phrase, you're
>>>>>>>>>>>>> wrong?
>>>>>>>>>>>>> So also this time.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> [...] the correct and complete simulation of a
>>>>>>>>>>>>>> machine description [...]
>>>>>>>>>>>>>
>>>>>>>>>>>>> Machine descriptions are never simulated -- they're just
>>>>>>>>>>>>> sequences
>>>>>>>>>>>>> of symbols.
>>>>>>>>>>>>> and don't have any defined behaviour. The machines they
>>>>>>>>>>>>> *represent*
>>>>>>>>>>>>> may be
>>>>>>>>>>>>> simulated.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> [...] always provides the actual behavior specified by
>>>>>>>>>>>>>> this machine description.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is almost, but not quite, correct (if you fix it
>>>>>>>>>>>>> according to
>>>>>>>>>>>>> the
>>>>>>>>>>>>> previous paragraph). It would have been completely correct,
>>>>>>>>>>>>> if it
>>>>>>>>>>>>> weren't
>>>>>>>>>>>>> for the fact that you're using an utterly bizarre meaning
>>>>>>>>>>>>> for the
>>>>>>>>>>>>> phrase
>>>>>>>>>>>>> "the actual behavior specified by this machine description".
>>>>>>>>>>>>>
>>>>>>>>>>>>>> That you and others reject this when it is applied to my
>>>>>>>>>>>>>> simulating halt
>>>>>>>>>>>>>> decider implicitly rejects the notion of a UTM. Since you
>>>>>>>>>>>>>> and others do
>>>>>>>>>>>>>> accept the notion of a UTM, I have just proven that your
>>>>>>>>>>>>>> reasoning is
>>>>>>>>>>>>>> incoherent and/or inconsistent.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Let M be a given machine, with machine description [M], and
>>>>>>>>>>>>> let w
>>>>>>>>>>>>> be
>>>>>>>>>>>>> a given input tape, with tape description [w]. Then the
>>>>>>>>>>>>> "simulation"
>>>>>>>>>>>>> UTM([M],[w]) has exactly the same result (i.e. exactly the
>>>>>>>>>>>>> same
>>>>>>>>>>>>> behaviour)
>>>>>>>>>>>>> as the direct computation M(w). This is actually the
>>>>>>>>>>>>> definition of
>>>>>>>>>>>>> a UTM.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Another way of expressing this is: M(w) and UTM([M],[w])
>>>>>>>>>>>>> compute
>>>>>>>>>>>>> the same
>>>>>>>>>>>>> partial function.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You have made it abundantly clear that when you say "the
>>>>>>>>>>>>> actual
>>>>>>>>>>>>> behavior
>>>>>>>>>>>>> specified by this machine description", you do *not* mean "the
>>>>>>>>>>>>> actual
>>>>>>>>>>>>> behavior specified by this machine description", because
>>>>>>>>>>>>> that's
>>>>>>>>>>>>> simply
>>>>>>>>>>>>> the behaviour of M(w). What you *do* mean is "the behaviour
>>>>>>>>>>>>> of your
>>>>>>>>>>>>> particular, broken and incomplete, quasi-simulation based
>>>>>>>>>>>>> on [M]
>>>>>>>>>>>>> and [w]".
>>>>>>>>>>>>>
>>>>>>>>>>>>> Why is it broken? Because it *doesn't* have the same
>>>>>>>>>>>>> behaviour as M
>>>>>>>>>>>>> (w),
>>>>>>>>>>>>> nor as UTM([M],[w]). A correct simulation *means* that it
>>>>>>>>>>>>> has the
>>>>>>>>>>>>> same
>>>>>>>>>>>>> behaviour as M(w).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Why is it incomplete? Because it aborts its "simulation"
>>>>>>>>>>>>> before it
>>>>>>>>>>>>> reaches
>>>>>>>>>>>>> a halting configuration of the machine represented by its
>>>>>>>>>>>>> input,
>>>>>>>>>>>>> and it
>>>>>>>>>>>>> does so on invalidly.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Why is it a quasi-simulation? Because it depends on
>>>>>>>>>>>>> external input
>>>>>>>>>>>>> that is
>>>>>>>>>>>>> contained in neither [M] nor [w]. You have said, on numerous
>>>>>>>>>>>>> occasions,
>>>>>>>>>>>>> that the behaviour of your "H(P,P)" depends on the specific
>>>>>>>>>>>>> memory
>>>>>>>>>>>>> location of "P". Well, then that location is an external
>>>>>>>>>>>>> input.
>>>>>>>>>>>>> Your H is
>>>>>>>>>>>>> *not* analogous to Linz' H([M],[w]).
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is the point where you usually barf up your stanza
>>>>>>>>>>>>> about how
>>>>>>>>>>>>> the
>>>>>>>>>>>>> behaviour of your "H(P,P)" cannot be expected to be
>>>>>>>>>>>>> computed "from
>>>>>>>>>>>>> the
>>>>>>>>>>>>> non-input P(P)". This is obviously idiotic, for the following
>>>>>>>>>>>>> reasons:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1) A purported halt decider H([M],[w]) is *not* required to
>>>>>>>>>>>>> compute
>>>>>>>>>>>>> its
>>>>>>>>>>>>>     result *from* M(w), but to *match* M(w). Computing
>>>>>>>>>>>>> *from* M(w)
>>>>>>>>>>>>> would be
>>>>>>>>>>>>>     completely pointless, because the decider would already
>>>>>>>>>>>>> know the
>>>>>>>>>>>>> answer.
>>>>>>>>>>>>>
>>>>>>>>>>>>>     Since you seem unable to understand anything but
>>>>>>>>>>>>> arguments from
>>>>>>>>>>>>>     analogy, let me re-use one that you yourself have
>>>>>>>>>>>>> employed:
>>>>>>>>>>>>> Suppose
>>>>>>>>>>>>>     we want to construct an addition algorithm add(x,y). If
>>>>>>>>>>>>> you were
>>>>>>>>>>>>> to
>>>>>>>>>>>>>     complain that add(5,7) cannot be required to compute
>>>>>>>>>>>>> its result
>>>>>>>>>>>>> "from
>>>>>>>>>>>>>     the non-input 12", you would, quite rightly, be
>>>>>>>>>>>>> regarded as a
>>>>>>>>>>>>> complete
>>>>>>>>>>>>>     nitwit. Can you now guess why you're universally
>>>>>>>>>>>>> regarded as a
>>>>>>>>>>>>> complete
>>>>>>>>>>>>>     nitwit?
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2) The behaviour of UTM([M],[w]) is *defined* to match the
>>>>>>>>>>>>> behaviour of M(w),
>>>>>>>>>>>>>     and UTMs very evidently do exist. The information
>>>>>>>>>>>>> contained in
>>>>>>>>>>>>> [M] and [w]
>>>>>>>>>>>>>     is obviously enough to match the behaviour of M(w). The
>>>>>>>>>>>>> fact
>>>>>>>>>>>>> that your
>>>>>>>>>>>>>     "simulator" fails in this regard, is proof that your
>>>>>>>>>>>>> "simulator" is
>>>>>>>>>>>>>     defective -- *not* that you have discovered a "loop
>>>>>>>>>>>>> hole", or
>>>>>>>>>>>>> that halting
>>>>>>>>>>>>>     theorem is faulty, or anything of that kind -- only
>>>>>>>>>>>>> that you're
>>>>>>>>>>>>> working
>>>>>>>>>>>>>     with a broken simulator.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> *NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE THERE IS
>>>>>>>>>>>>>> NO ERROR*
>>>>>>>>>>>>>
>>>>>>>>>>>>> A lot of people have pointed out many kinds of errors in your
>>>>>>>>>>>>> reasoning.
>>>>>>>>>>>>> You usually respond with some form "proof by regurgitation". I
>>>>>>>>>>>>> expect you
>>>>>>>>>>>>> will do so to this post.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> When-so-ever a simulating halt decider (SHD) correctly
>>>>>>>>>>>>>> performs a
>>>>>>>>>>>>>> partial simulation of its input and the behavior of this
>>>>>>>>>>>>>> partial
>>>>>>>>>>>>>> simulation correctly matches a non-halting behavior
>>>>>>>>>>>>>> pattern then the SHD
>>>>>>>>>>>>>> halt decider can correctly report non-halting.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> A non-halting behavior pattern is correct when-so-ever
>>>>>>>>>>>>>> matching this
>>>>>>>>>>>>>> behavior pattern proves that the correct and complete
>>>>>>>>>>>>>> simulation of the
>>>>>>>>>>>>>> input by SHD would never reach the final state of this
>>>>>>>>>>>>>> simulated input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yeah, that's just a bunch of equivocations on "correctly",
>>>>>>>>>>>>> "its
>>>>>>>>>>>>> input",
>>>>>>>>>>>>> "non-halting behavior", and more.  Please learn to write
>>>>>>>>>>>>> clearly.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Also, could you *please* stop misreading Linz! He *doesn't*
>>>>>>>>>>>>> say
>>>>>>>>>>>>> that a TM
>>>>>>>>>>>>> halts, only if it enters a "final state". What he actually
>>>>>>>>>>>>> says is:
>>>>>>>>>>>>>
>>>>>>>>>>>>>      "A Turing machine is said to halt whenever it reaches a
>>>>>>>>>>>>> configuration
>>>>>>>>>>>>>      for which delta is not defined; this is possible
>>>>>>>>>>>>> because delta
>>>>>>>>>>>>> is a
>>>>>>>>>>>>>      partial function. In fact, we will assume that no
>>>>>>>>>>>>> transitions
>>>>>>>>>>>>> are
>>>>>>>>>>>>>      defined for any final state, so the Turing machine
>>>>>>>>>>>>> will halt
>>>>>>>>>>>>> whenever
>>>>>>>>>>>>>      it enters a final state."
>>>>>>>>>>>>>
>>>>>>>>>>>>> So, for a general TM, there may well be configurations for
>>>>>>>>>>>>> which
>>>>>>>>>>>>> the TM
>>>>>>>>>>>>> halts in a non-final state. It is, on the other hand,
>>>>>>>>>>>>> understood
>>>>>>>>>>>>> that a TM
>>>>>>>>>>>>> *only* stops running if enters a configuration for which the
>>>>>>>>>>>>> transition
>>>>>>>>>>>>> function is undefined.
>>>>>>>>>>>>>
>>>>>>>>>>>>> "Final states" only concern the *interpretation* of the
>>>>>>>>>>>>> value of a
>>>>>>>>>>>>> computation -- *not* whether the TM halts or not.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This means that "halting" and "stops running" are the exact
>>>>>>>>>>>>> the
>>>>>>>>>>>>> same things.
>>>>>>>>>>>>> And obviously, "running" and "being simulated" are two
>>>>>>>>>>>>> entirely
>>>>>>>>>>>>> different
>>>>>>>>>>>>> things.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>> {
>>>>>>>>>>>>    int Halt_Status = UTM(x, x);
>>>>>>>>>>>>    if (Halt_Status)
>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>>    return;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> The behavior of the actual input to the simulating halt
>>>>>>>>>>>> decider is the behavior of the above. Since C functions do
>>>>>>>>>>>> not actually have UTM's a more accurate way of sayoing this is:
>>>>>>>>>>>>
>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>> {
>>>>>>>>>>>>    int Halt_Status = Simulate(x, x);
>>>>>>>>>>>>    if (Halt_Status)
>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>>    return;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> The behavior of UTM(P,P) or Simulate(P,P) is not the
>>>>>>>>>>>> behavior of the actual input to H(P,P) because it is at a
>>>>>>>>>>>> different point in the execution trace than H(P,P).
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Wrong, at least if H is supposed to be a Halt Decider.
>>>>>>>>>>>
>>>>>>>>>>> You forget the question that the Halt Decider is being asked
>>>>>>>>>>> to solve, which is what the machine represented by its input
>>>>>>>>>>> would do.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> It is common knowledge that the correct and complete
>>>>>>>>>> simulation of a machine description always provides the actual
>>>>>>>>>> behavior specified by this machine description.
>>>>>>>>>
>>>>>>>>> Right.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> That you (and others such as Ben) reject that the correct and
>>>>>>>>>> complete simulation by H(P,P) of its input does provide the
>>>>>>>>>> actual behavior of this input also rejects the notion of a UTM
>>>>>>>>>> which you accept, thus you (and all others holding this view
>>>>>>>>>> such as Ben) contradict yourself (themselves).
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So, why do you reject the actual correct and complete
>>>>>>>>> simulation of the input to H when done by an actual pure
>>>>>>>>> simulator/UTM?
>>>>>>>>>
>>>>>>>> As long as it is done at the exact point in the execution trace
>>>>>>>> as H(P,P) then it is fine, otherwise it is not the same as the
>>>>>>>> simulation by H(P,P).
>>>>>>>>
>>>>>>>
>>>>>>> The simulation of the input to H(P,P) is the simulation of the
>>>>>>> instruction sequence specified by the code of P (and the routines
>>>>>>> it calls) and has ZERO dependency on what happened before that call
>>>>>>
>>>>>> main()
>>>>>> {
>>>>>>    P(P); // depends on the return value from H(P,P);
>>>>>> }
>>>>>>
>>>>>> The input to H(P,P) that H correctly simulates cannot possibly
>>>>>> depend on the return value from H because this return value is
>>>>>> unreachable by P:
>>>>>
>>>>> But it NEEDS to. That fact that it can't get the needed value
>>>>> because of the limitation of your algorithm, doesn't mean it gets
>>>>> to ignore it.
>>>>>
>>>>> Not, Mr Flibble has shown a way that H CAN determine the behavior
>>>>> of P based on the return value of H, even though H can simulate the
>>>>> path through itself.
>>>>>
>>>>> (As I pointed out a long time ago too).
>>>>
>>>> Every function that is called in infinite recursion cannot possibly
>>>> correctly return to its caller. People that believe that it can are
>>>> as wrong as if they disagreed with arithmetic.
>>>>
>>>> If computer science says that a function called in finite recursion
>>>> must return to its caller then computer science is wrong, one might
>>>> as well have said the cats must be dogs.
>>>>
>>>>>>
>>>>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>>>>>> (b) that simulates P(P) that calls a simulated H(P,P)
>>>>>> (c) that simulates P(P) that calls a simulated H(P,P)
>>>>>> (d) that simulates P(P) that calls a simulated H(P,P)...
>>>>>> *Until H aborts its simulation*
>>>>>>
>>>>>> This dependency difference causes the different behavior between
>>>>>> the simulated P and the executed P.
>>>>>
>>>>> Nope, the CORRECT AND COMPLETE simulation of the input does depend
>>>>> on the value that H(P,P) returns, unless H(P,P) never returns a
>>>>> value to ANYBODY.
>>>>>
>>>>> Your H just gets it wrong because it "guesses" wrong because it
>>>>> used unsound logic.
>>>>>
>>>>
>>>> You know that it did not merely guess.
>>>> You know that the correct and complete simulation by H(P,P) of its
>>>> input would never reach the final state of this input.
>>>
>>> No, that is a MEANINGLESS statement, because you H doesn't DO a
>>> complete simulation.
>>>
>>
>>
>> Do you know how ridiculously stupid it is of you of you to suggest
>> that a simulating halt decider perform a complete simulation of its
>> non-halting input?
>
> I never said it did. YOUR DEFINITION says it must,

On 8/22/22 10:32 PM, olcott wrote:
> On 8/22/2022 6:58 PM, Richard Damon wrote:
>> On 8/22/22 7:33 PM, olcott wrote:
>>> On 8/22/2022 6:21 PM, Richard Damon wrote:
>>>> On 8/22/22 10:31 AM, olcott wrote:
>>>>> On 8/21/2022 10:37 PM, Richard Damon wrote:
>>>>>> On 8/21/22 11:27 PM, olcott wrote:
>>>>>>> On 8/21/2022 10:14 PM, Richard Damon wrote:
>>>>>>>> On 8/21/22 9:37 PM, olcott wrote:
>>>>>>>>> On 8/21/2022 8:04 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 8/21/22 8:45 PM, olcott wrote:
>>>>>>>>>>> On 8/21/2022 1:04 PM, Richard Damon wrote:
>>>>>>>>>>>> On 8/21/22 11:36 AM, olcott wrote:
>>>>>>>>>>>>> On 8/21/2022 10:16 AM, Shvili, the Kookologist wrote:
>>>>>>>>>>>>>> On Sat, 20 Aug 2022 16:01:31 -0500, in article
>>>>>>>>>>>>>> <crudnRbncP4E1pz-
>>>>>>>>>>>>>> nZ2dnZfqlJzNnZ2d@giganews.com>, olcott wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [snip]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is common knowledge that [...]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Have you noticed that almost every time you use this
>>>>>>>>>>>>>> phrase, you're
>>>>>>>>>>>>>> wrong?
>>>>>>>>>>>>>> So also this time.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [...] the correct and complete simulation of a
>>>>>>>>>>>>>>> machine description [...]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Machine descriptions are never simulated -- they're just
>>>>>>>>>>>>>> sequences
>>>>>>>>>>>>>> of symbols.
>>>>>>>>>>>>>> and don't have any defined behaviour. The machines they
>>>>>>>>>>>>>> *represent*
>>>>>>>>>>>>>> may be
>>>>>>>>>>>>>> simulated.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [...] always provides the actual behavior specified by
>>>>>>>>>>>>>>> this machine description.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is almost, but not quite, correct (if you fix it
>>>>>>>>>>>>>> according to
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> previous paragraph). It would have been completely
>>>>>>>>>>>>>> correct, if it
>>>>>>>>>>>>>> weren't
>>>>>>>>>>>>>> for the fact that you're using an utterly bizarre meaning
>>>>>>>>>>>>>> for the
>>>>>>>>>>>>>> phrase
>>>>>>>>>>>>>> "the actual behavior specified by this machine description".
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That you and others reject this when it is applied to my
>>>>>>>>>>>>>>> simulating halt
>>>>>>>>>>>>>>> decider implicitly rejects the notion of a UTM. Since you
>>>>>>>>>>>>>>> and others do
>>>>>>>>>>>>>>> accept the notion of a UTM, I have just proven that your
>>>>>>>>>>>>>>> reasoning is
>>>>>>>>>>>>>>> incoherent and/or inconsistent.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Let M be a given machine, with machine description [M],
>>>>>>>>>>>>>> and let w
>>>>>>>>>>>>>> be
>>>>>>>>>>>>>> a given input tape, with tape description [w]. Then the
>>>>>>>>>>>>>> "simulation"
>>>>>>>>>>>>>> UTM([M],[w]) has exactly the same result (i.e. exactly the
>>>>>>>>>>>>>> same
>>>>>>>>>>>>>> behaviour)
>>>>>>>>>>>>>> as the direct computation M(w). This is actually the
>>>>>>>>>>>>>> definition of
>>>>>>>>>>>>>> a UTM.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Another way of expressing this is: M(w) and UTM([M],[w])
>>>>>>>>>>>>>> compute
>>>>>>>>>>>>>> the same
>>>>>>>>>>>>>> partial function.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You have made it abundantly clear that when you say "the
>>>>>>>>>>>>>> actual
>>>>>>>>>>>>>> behavior
>>>>>>>>>>>>>> specified by this machine description", you do *not* mean
>>>>>>>>>>>>>> "the
>>>>>>>>>>>>>> actual
>>>>>>>>>>>>>> behavior specified by this machine description", because
>>>>>>>>>>>>>> that's
>>>>>>>>>>>>>> simply
>>>>>>>>>>>>>> the behaviour of M(w). What you *do* mean is "the
>>>>>>>>>>>>>> behaviour of your
>>>>>>>>>>>>>> particular, broken and incomplete, quasi-simulation based
>>>>>>>>>>>>>> on [M]
>>>>>>>>>>>>>> and [w]".
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Why is it broken? Because it *doesn't* have the same
>>>>>>>>>>>>>> behaviour as M
>>>>>>>>>>>>>> (w),
>>>>>>>>>>>>>> nor as UTM([M],[w]). A correct simulation *means* that it
>>>>>>>>>>>>>> has the
>>>>>>>>>>>>>> same
>>>>>>>>>>>>>> behaviour as M(w).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Why is it incomplete? Because it aborts its "simulation"
>>>>>>>>>>>>>> before it
>>>>>>>>>>>>>> reaches
>>>>>>>>>>>>>> a halting configuration of the machine represented by its
>>>>>>>>>>>>>> input,
>>>>>>>>>>>>>> and it
>>>>>>>>>>>>>> does so on invalidly.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Why is it a quasi-simulation? Because it depends on
>>>>>>>>>>>>>> external input
>>>>>>>>>>>>>> that is
>>>>>>>>>>>>>> contained in neither [M] nor [w]. You have said, on numerous
>>>>>>>>>>>>>> occasions,
>>>>>>>>>>>>>> that the behaviour of your "H(P,P)" depends on the
>>>>>>>>>>>>>> specific memory
>>>>>>>>>>>>>> location of "P". Well, then that location is an external
>>>>>>>>>>>>>> input.
>>>>>>>>>>>>>> Your H is
>>>>>>>>>>>>>> *not* analogous to Linz' H([M],[w]).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is the point where you usually barf up your stanza
>>>>>>>>>>>>>> about how
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> behaviour of your "H(P,P)" cannot be expected to be
>>>>>>>>>>>>>> computed "from
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> non-input P(P)". This is obviously idiotic, for the following
>>>>>>>>>>>>>> reasons:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1) A purported halt decider H([M],[w]) is *not* required
>>>>>>>>>>>>>> to compute
>>>>>>>>>>>>>> its
>>>>>>>>>>>>>>     result *from* M(w), but to *match* M(w). Computing
>>>>>>>>>>>>>> *from* M(w)
>>>>>>>>>>>>>> would be
>>>>>>>>>>>>>>     completely pointless, because the decider would
>>>>>>>>>>>>>> already know the
>>>>>>>>>>>>>> answer.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     Since you seem unable to understand anything but
>>>>>>>>>>>>>> arguments from
>>>>>>>>>>>>>>     analogy, let me re-use one that you yourself have
>>>>>>>>>>>>>> employed:
>>>>>>>>>>>>>> Suppose
>>>>>>>>>>>>>>     we want to construct an addition algorithm add(x,y).
>>>>>>>>>>>>>> If you were
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>     complain that add(5,7) cannot be required to compute
>>>>>>>>>>>>>> its result
>>>>>>>>>>>>>> "from
>>>>>>>>>>>>>>     the non-input 12", you would, quite rightly, be
>>>>>>>>>>>>>> regarded as a
>>>>>>>>>>>>>> complete
>>>>>>>>>>>>>>     nitwit. Can you now guess why you're universally
>>>>>>>>>>>>>> regarded as a
>>>>>>>>>>>>>> complete
>>>>>>>>>>>>>>     nitwit?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2) The behaviour of UTM([M],[w]) is *defined* to match the
>>>>>>>>>>>>>> behaviour of M(w),
>>>>>>>>>>>>>>     and UTMs very evidently do exist. The information
>>>>>>>>>>>>>> contained in
>>>>>>>>>>>>>> [M] and [w]
>>>>>>>>>>>>>>     is obviously enough to match the behaviour of M(w).
>>>>>>>>>>>>>> The fact
>>>>>>>>>>>>>> that your
>>>>>>>>>>>>>>     "simulator" fails in this regard, is proof that your
>>>>>>>>>>>>>> "simulator" is
>>>>>>>>>>>>>>     defective -- *not* that you have discovered a "loop
>>>>>>>>>>>>>> hole", or
>>>>>>>>>>>>>> that halting
>>>>>>>>>>>>>>     theorem is faulty, or anything of that kind -- only
>>>>>>>>>>>>>> that you're
>>>>>>>>>>>>>> working
>>>>>>>>>>>>>>     with a broken simulator.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE THERE IS
>>>>>>>>>>>>>>> NO ERROR*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> A lot of people have pointed out many kinds of errors in your
>>>>>>>>>>>>>> reasoning.
>>>>>>>>>>>>>> You usually respond with some form "proof by
>>>>>>>>>>>>>> regurgitation". I
>>>>>>>>>>>>>> expect you
>>>>>>>>>>>>>> will do so to this post.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When-so-ever a simulating halt decider (SHD) correctly
>>>>>>>>>>>>>>> performs a
>>>>>>>>>>>>>>> partial simulation of its input and the behavior of this
>>>>>>>>>>>>>>> partial
>>>>>>>>>>>>>>> simulation correctly matches a non-halting behavior
>>>>>>>>>>>>>>> pattern then the SHD
>>>>>>>>>>>>>>> halt decider can correctly report non-halting.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A non-halting behavior pattern is correct when-so-ever
>>>>>>>>>>>>>>> matching this
>>>>>>>>>>>>>>> behavior pattern proves that the correct and complete
>>>>>>>>>>>>>>> simulation of the
>>>>>>>>>>>>>>> input by SHD would never reach the final state of this
>>>>>>>>>>>>>>> simulated input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yeah, that's just a bunch of equivocations on "correctly",
>>>>>>>>>>>>>> "its
>>>>>>>>>>>>>> input",
>>>>>>>>>>>>>> "non-halting behavior", and more.  Please learn to write
>>>>>>>>>>>>>> clearly.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Also, could you *please* stop misreading Linz! He
>>>>>>>>>>>>>> *doesn't* say
>>>>>>>>>>>>>> that a TM
>>>>>>>>>>>>>> halts, only if it enters a "final state". What he actually
>>>>>>>>>>>>>> says is:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>      "A Turing machine is said to halt whenever it reaches a
>>>>>>>>>>>>>> configuration
>>>>>>>>>>>>>>      for which delta is not defined; this is possible
>>>>>>>>>>>>>> because delta
>>>>>>>>>>>>>> is a
>>>>>>>>>>>>>>      partial function. In fact, we will assume that no
>>>>>>>>>>>>>> transitions
>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>      defined for any final state, so the Turing machine
>>>>>>>>>>>>>> will halt
>>>>>>>>>>>>>> whenever
>>>>>>>>>>>>>>      it enters a final state."
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, for a general TM, there may well be configurations for
>>>>>>>>>>>>>> which
>>>>>>>>>>>>>> the TM
>>>>>>>>>>>>>> halts in a non-final state. It is, on the other hand,
>>>>>>>>>>>>>> understood
>>>>>>>>>>>>>> that a TM
>>>>>>>>>>>>>> *only* stops running if enters a configuration for which the
>>>>>>>>>>>>>> transition
>>>>>>>>>>>>>> function is undefined.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> "Final states" only concern the *interpretation* of the
>>>>>>>>>>>>>> value of a
>>>>>>>>>>>>>> computation -- *not* whether the TM halts or not.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This means that "halting" and "stops running" are the
>>>>>>>>>>>>>> exact the
>>>>>>>>>>>>>> same things.
>>>>>>>>>>>>>> And obviously, "running" and "being simulated" are two
>>>>>>>>>>>>>> entirely
>>>>>>>>>>>>>> different
>>>>>>>>>>>>>> things.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>> {
>>>>>>>>>>>>>    int Halt_Status = UTM(x, x);
>>>>>>>>>>>>>    if (Halt_Status)
>>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>>>    return;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> The behavior of the actual input to the simulating halt
>>>>>>>>>>>>> decider is the behavior of the above. Since C functions do
>>>>>>>>>>>>> not actually have UTM's a more accurate way of sayoing this
>>>>>>>>>>>>> is:
>>>>>>>>>>>>>
>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>> {
>>>>>>>>>>>>>    int Halt_Status = Simulate(x, x);
>>>>>>>>>>>>>    if (Halt_Status)
>>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>>>    return;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> The behavior of UTM(P,P) or Simulate(P,P) is not the
>>>>>>>>>>>>> behavior of the actual input to H(P,P) because it is at a
>>>>>>>>>>>>> different point in the execution trace than H(P,P).
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Wrong, at least if H is supposed to be a Halt Decider.
>>>>>>>>>>>>
>>>>>>>>>>>> You forget the question that the Halt Decider is being asked
>>>>>>>>>>>> to solve, which is what the machine represented by its input
>>>>>>>>>>>> would do.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> It is common knowledge that the correct and complete
>>>>>>>>>>> simulation of a machine description always provides the
>>>>>>>>>>> actual behavior specified by this machine description.
>>>>>>>>>>
>>>>>>>>>> Right.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> That you (and others such as Ben) reject that the correct and
>>>>>>>>>>> complete simulation by H(P,P) of its input does provide the
>>>>>>>>>>> actual behavior of this input also rejects the notion of a
>>>>>>>>>>> UTM which you accept, thus you (and all others holding this
>>>>>>>>>>> view such as Ben) contradict yourself (themselves).
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So, why do you reject the actual correct and complete
>>>>>>>>>> simulation of the input to H when done by an actual pure
>>>>>>>>>> simulator/UTM?
>>>>>>>>>>
>>>>>>>>> As long as it is done at the exact point in the execution trace
>>>>>>>>> as H(P,P) then it is fine, otherwise it is not the same as the
>>>>>>>>> simulation by H(P,P).
>>>>>>>>>
>>>>>>>>
>>>>>>>> The simulation of the input to H(P,P) is the simulation of the
>>>>>>>> instruction sequence specified by the code of P (and the
>>>>>>>> routines it calls) and has ZERO dependency on what happened
>>>>>>>> before that call
>>>>>>>
>>>>>>> main()
>>>>>>> {
>>>>>>>    P(P); // depends on the return value from H(P,P);
>>>>>>> }
>>>>>>>
>>>>>>> The input to H(P,P) that H correctly simulates cannot possibly
>>>>>>> depend on the return value from H because this return value is
>>>>>>> unreachable by P:
>>>>>>
>>>>>> But it NEEDS to. That fact that it can't get the needed value
>>>>>> because of the limitation of your algorithm, doesn't mean it gets
>>>>>> to ignore it.
>>>>>>
>>>>>> Not, Mr Flibble has shown a way that H CAN determine the behavior
>>>>>> of P based on the return value of H, even though H can simulate
>>>>>> the path through itself.
>>>>>>
>>>>>> (As I pointed out a long time ago too).
>>>>>
>>>>> Every function that is called in infinite recursion cannot possibly
>>>>> correctly return to its caller. People that believe that it can are
>>>>> as wrong as if they disagreed with arithmetic.
>>>>>
>>>>> If computer science says that a function called in finite recursion
>>>>> must return to its caller then computer science is wrong, one might
>>>>> as well have said the cats must be dogs.
>>>>>
>>>>>>>
>>>>>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>>>>>>> (b) that simulates P(P) that calls a simulated H(P,P)
>>>>>>> (c) that simulates P(P) that calls a simulated H(P,P)
>>>>>>> (d) that simulates P(P) that calls a simulated H(P,P)...
>>>>>>> *Until H aborts its simulation*
>>>>>>>
>>>>>>> This dependency difference causes the different behavior between
>>>>>>> the simulated P and the executed P.
>>>>>>
>>>>>> Nope, the CORRECT AND COMPLETE simulation of the input does depend
>>>>>> on the value that H(P,P) returns, unless H(P,P) never returns a
>>>>>> value to ANYBODY.
>>>>>>
>>>>>> Your H just gets it wrong because it "guesses" wrong because it
>>>>>> used unsound logic.
>>>>>>
>>>>>
>>>>> You know that it did not merely guess.
>>>>> You know that the correct and complete simulation by H(P,P) of its
>>>>> input would never reach the final state of this input.
>>>>
>>>> No, that is a MEANINGLESS statement, because you H doesn't DO a
>>>> complete simulation.
>>>>
>>>
>>>
>>> Do you know how ridiculously stupid it is of you of you to suggest
>>> that a simulating halt decider perform a complete simulation of its
>>> non-halting input?
>>
>> I never said it did. YOUR DEFINITION says it must,
>
>
> *No knucklehead I never said anything like that, here is what I said*
>
> It is common knowledge that the correct and complete simulation of a
> machine description always provides the actual behavior specified by
> this machine description.

On 8/22/2022 9:44 PM, Richard Damon wrote:
> On 8/22/22 10:32 PM, olcott wrote:
>> On 8/22/2022 6:58 PM, Richard Damon wrote:
>>> On 8/22/22 7:33 PM, olcott wrote:
>>>> On 8/22/2022 6:21 PM, Richard Damon wrote:
>>>>> On 8/22/22 10:31 AM, olcott wrote:
>>>>>> On 8/21/2022 10:37 PM, Richard Damon wrote:
>>>>>>> On 8/21/22 11:27 PM, olcott wrote:
>>>>>>>> On 8/21/2022 10:14 PM, Richard Damon wrote:
>>>>>>>>> On 8/21/22 9:37 PM, olcott wrote:
>>>>>>>>>> On 8/21/2022 8:04 PM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 8/21/22 8:45 PM, olcott wrote:
>>>>>>>>>>>> On 8/21/2022 1:04 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 8/21/22 11:36 AM, olcott wrote:
>>>>>>>>>>>>>> On 8/21/2022 10:16 AM, Shvili, the Kookologist wrote:
>>>>>>>>>>>>>>> On Sat, 20 Aug 2022 16:01:31 -0500, in article
>>>>>>>>>>>>>>> <crudnRbncP4E1pz-
>>>>>>>>>>>>>>> nZ2dnZfqlJzNnZ2d@giganews.com>, olcott wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [snip]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It is common knowledge that [...]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Have you noticed that almost every time you use this
>>>>>>>>>>>>>>> phrase, you're
>>>>>>>>>>>>>>> wrong?
>>>>>>>>>>>>>>> So also this time.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> [...] the correct and complete simulation of a
>>>>>>>>>>>>>>>> machine description [...]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Machine descriptions are never simulated -- they're just
>>>>>>>>>>>>>>> sequences
>>>>>>>>>>>>>>> of symbols.
>>>>>>>>>>>>>>> and don't have any defined behaviour. The machines they
>>>>>>>>>>>>>>> *represent*
>>>>>>>>>>>>>>> may be
>>>>>>>>>>>>>>> simulated.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> [...] always provides the actual behavior specified by
>>>>>>>>>>>>>>>> this machine description.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This is almost, but not quite, correct (if you fix it
>>>>>>>>>>>>>>> according to
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> previous paragraph). It would have been completely
>>>>>>>>>>>>>>> correct, if it
>>>>>>>>>>>>>>> weren't
>>>>>>>>>>>>>>> for the fact that you're using an utterly bizarre meaning
>>>>>>>>>>>>>>> for the
>>>>>>>>>>>>>>> phrase
>>>>>>>>>>>>>>> "the actual behavior specified by this machine description".
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That you and others reject this when it is applied to my
>>>>>>>>>>>>>>>> simulating halt
>>>>>>>>>>>>>>>> decider implicitly rejects the notion of a UTM. Since
>>>>>>>>>>>>>>>> you and others do
>>>>>>>>>>>>>>>> accept the notion of a UTM, I have just proven that your
>>>>>>>>>>>>>>>> reasoning is
>>>>>>>>>>>>>>>> incoherent and/or inconsistent.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Let M be a given machine, with machine description [M],
>>>>>>>>>>>>>>> and let w
>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>> a given input tape, with tape description [w]. Then the
>>>>>>>>>>>>>>> "simulation"
>>>>>>>>>>>>>>> UTM([M],[w]) has exactly the same result (i.e. exactly
>>>>>>>>>>>>>>> the same
>>>>>>>>>>>>>>> behaviour)
>>>>>>>>>>>>>>> as the direct computation M(w). This is actually the
>>>>>>>>>>>>>>> definition of
>>>>>>>>>>>>>>> a UTM.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Another way of expressing this is: M(w) and UTM([M],[w])
>>>>>>>>>>>>>>> compute
>>>>>>>>>>>>>>> the same
>>>>>>>>>>>>>>> partial function.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You have made it abundantly clear that when you say "the
>>>>>>>>>>>>>>> actual
>>>>>>>>>>>>>>> behavior
>>>>>>>>>>>>>>> specified by this machine description", you do *not* mean
>>>>>>>>>>>>>>> "the
>>>>>>>>>>>>>>> actual
>>>>>>>>>>>>>>> behavior specified by this machine description", because
>>>>>>>>>>>>>>> that's
>>>>>>>>>>>>>>> simply
>>>>>>>>>>>>>>> the behaviour of M(w). What you *do* mean is "the
>>>>>>>>>>>>>>> behaviour of your
>>>>>>>>>>>>>>> particular, broken and incomplete, quasi-simulation based
>>>>>>>>>>>>>>> on [M]
>>>>>>>>>>>>>>> and [w]".
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Why is it broken? Because it *doesn't* have the same
>>>>>>>>>>>>>>> behaviour as M
>>>>>>>>>>>>>>> (w),
>>>>>>>>>>>>>>> nor as UTM([M],[w]). A correct simulation *means* that it
>>>>>>>>>>>>>>> has the
>>>>>>>>>>>>>>> same
>>>>>>>>>>>>>>> behaviour as M(w).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Why is it incomplete? Because it aborts its "simulation"
>>>>>>>>>>>>>>> before it
>>>>>>>>>>>>>>> reaches
>>>>>>>>>>>>>>> a halting configuration of the machine represented by its
>>>>>>>>>>>>>>> input,
>>>>>>>>>>>>>>> and it
>>>>>>>>>>>>>>> does so on invalidly.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Why is it a quasi-simulation? Because it depends on
>>>>>>>>>>>>>>> external input
>>>>>>>>>>>>>>> that is
>>>>>>>>>>>>>>> contained in neither [M] nor [w]. You have said, on numerous
>>>>>>>>>>>>>>> occasions,
>>>>>>>>>>>>>>> that the behaviour of your "H(P,P)" depends on the
>>>>>>>>>>>>>>> specific memory
>>>>>>>>>>>>>>> location of "P". Well, then that location is an external
>>>>>>>>>>>>>>> input.
>>>>>>>>>>>>>>> Your H is
>>>>>>>>>>>>>>> *not* analogous to Linz' H([M],[w]).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This is the point where you usually barf up your stanza
>>>>>>>>>>>>>>> about how
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> behaviour of your "H(P,P)" cannot be expected to be
>>>>>>>>>>>>>>> computed "from
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> non-input P(P)". This is obviously idiotic, for the
>>>>>>>>>>>>>>> following
>>>>>>>>>>>>>>> reasons:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 1) A purported halt decider H([M],[w]) is *not* required
>>>>>>>>>>>>>>> to compute
>>>>>>>>>>>>>>> its
>>>>>>>>>>>>>>>     result *from* M(w), but to *match* M(w). Computing
>>>>>>>>>>>>>>> *from* M(w)
>>>>>>>>>>>>>>> would be
>>>>>>>>>>>>>>>     completely pointless, because the decider would
>>>>>>>>>>>>>>> already know the
>>>>>>>>>>>>>>> answer.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>     Since you seem unable to understand anything but
>>>>>>>>>>>>>>> arguments from
>>>>>>>>>>>>>>>     analogy, let me re-use one that you yourself have
>>>>>>>>>>>>>>> employed:
>>>>>>>>>>>>>>> Suppose
>>>>>>>>>>>>>>>     we want to construct an addition algorithm add(x,y).
>>>>>>>>>>>>>>> If you were
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>     complain that add(5,7) cannot be required to compute
>>>>>>>>>>>>>>> its result
>>>>>>>>>>>>>>> "from
>>>>>>>>>>>>>>>     the non-input 12", you would, quite rightly, be
>>>>>>>>>>>>>>> regarded as a
>>>>>>>>>>>>>>> complete
>>>>>>>>>>>>>>>     nitwit. Can you now guess why you're universally
>>>>>>>>>>>>>>> regarded as a
>>>>>>>>>>>>>>> complete
>>>>>>>>>>>>>>>     nitwit?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2) The behaviour of UTM([M],[w]) is *defined* to match the
>>>>>>>>>>>>>>> behaviour of M(w),
>>>>>>>>>>>>>>>     and UTMs very evidently do exist. The information
>>>>>>>>>>>>>>> contained in
>>>>>>>>>>>>>>> [M] and [w]
>>>>>>>>>>>>>>>     is obviously enough to match the behaviour of M(w).
>>>>>>>>>>>>>>> The fact
>>>>>>>>>>>>>>> that your
>>>>>>>>>>>>>>>     "simulator" fails in this regard, is proof that your
>>>>>>>>>>>>>>> "simulator" is
>>>>>>>>>>>>>>>     defective -- *not* that you have discovered a "loop
>>>>>>>>>>>>>>> hole", or
>>>>>>>>>>>>>>> that halting
>>>>>>>>>>>>>>>     theorem is faulty, or anything of that kind -- only
>>>>>>>>>>>>>>> that you're
>>>>>>>>>>>>>>> working
>>>>>>>>>>>>>>>     with a broken simulator.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE THERE
>>>>>>>>>>>>>>>> IS NO ERROR*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A lot of people have pointed out many kinds of errors in
>>>>>>>>>>>>>>> your
>>>>>>>>>>>>>>> reasoning.
>>>>>>>>>>>>>>> You usually respond with some form "proof by
>>>>>>>>>>>>>>> regurgitation". I
>>>>>>>>>>>>>>> expect you
>>>>>>>>>>>>>>> will do so to this post.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> When-so-ever a simulating halt decider (SHD) correctly
>>>>>>>>>>>>>>>> performs a
>>>>>>>>>>>>>>>> partial simulation of its input and the behavior of this
>>>>>>>>>>>>>>>> partial
>>>>>>>>>>>>>>>> simulation correctly matches a non-halting behavior
>>>>>>>>>>>>>>>> pattern then the SHD
>>>>>>>>>>>>>>>> halt decider can correctly report non-halting.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A non-halting behavior pattern is correct when-so-ever
>>>>>>>>>>>>>>>> matching this
>>>>>>>>>>>>>>>> behavior pattern proves that the correct and complete
>>>>>>>>>>>>>>>> simulation of the
>>>>>>>>>>>>>>>> input by SHD would never reach the final state of this
>>>>>>>>>>>>>>>> simulated input.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yeah, that's just a bunch of equivocations on
>>>>>>>>>>>>>>> "correctly", "its
>>>>>>>>>>>>>>> input",
>>>>>>>>>>>>>>> "non-halting behavior", and more.  Please learn to write
>>>>>>>>>>>>>>> clearly.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Also, could you *please* stop misreading Linz! He
>>>>>>>>>>>>>>> *doesn't* say
>>>>>>>>>>>>>>> that a TM
>>>>>>>>>>>>>>> halts, only if it enters a "final state". What he
>>>>>>>>>>>>>>> actually says is:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>      "A Turing machine is said to halt whenever it reaches a
>>>>>>>>>>>>>>> configuration
>>>>>>>>>>>>>>>      for which delta is not defined; this is possible
>>>>>>>>>>>>>>> because delta
>>>>>>>>>>>>>>> is a
>>>>>>>>>>>>>>>      partial function. In fact, we will assume that no
>>>>>>>>>>>>>>> transitions
>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>      defined for any final state, so the Turing machine
>>>>>>>>>>>>>>> will halt
>>>>>>>>>>>>>>> whenever
>>>>>>>>>>>>>>>      it enters a final state."
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So, for a general TM, there may well be configurations
>>>>>>>>>>>>>>> for which
>>>>>>>>>>>>>>> the TM
>>>>>>>>>>>>>>> halts in a non-final state. It is, on the other hand,
>>>>>>>>>>>>>>> understood
>>>>>>>>>>>>>>> that a TM
>>>>>>>>>>>>>>> *only* stops running if enters a configuration for which the
>>>>>>>>>>>>>>> transition
>>>>>>>>>>>>>>> function is undefined.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> "Final states" only concern the *interpretation* of the
>>>>>>>>>>>>>>> value of a
>>>>>>>>>>>>>>> computation -- *not* whether the TM halts or not.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This means that "halting" and "stops running" are the
>>>>>>>>>>>>>>> exact the
>>>>>>>>>>>>>>> same things.
>>>>>>>>>>>>>>> And obviously, "running" and "being simulated" are two
>>>>>>>>>>>>>>> entirely
>>>>>>>>>>>>>>> different
>>>>>>>>>>>>>>> things.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>    int Halt_Status = UTM(x, x);
>>>>>>>>>>>>>>    if (Halt_Status)
>>>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>>>>    return;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The behavior of the actual input to the simulating halt
>>>>>>>>>>>>>> decider is the behavior of the above. Since C functions do
>>>>>>>>>>>>>> not actually have UTM's a more accurate way of sayoing
>>>>>>>>>>>>>> this is:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>    int Halt_Status = Simulate(x, x);
>>>>>>>>>>>>>>    if (Halt_Status)
>>>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>>>>    return;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The behavior of UTM(P,P) or Simulate(P,P) is not the
>>>>>>>>>>>>>> behavior of the actual input to H(P,P) because it is at a
>>>>>>>>>>>>>> different point in the execution trace than H(P,P).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Wrong, at least if H is supposed to be a Halt Decider.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You forget the question that the Halt Decider is being
>>>>>>>>>>>>> asked to solve, which is what the machine represented by
>>>>>>>>>>>>> its input would do.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> It is common knowledge that the correct and complete
>>>>>>>>>>>> simulation of a machine description always provides the
>>>>>>>>>>>> actual behavior specified by this machine description.
>>>>>>>>>>>
>>>>>>>>>>> Right.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> That you (and others such as Ben) reject that the correct
>>>>>>>>>>>> and complete simulation by H(P,P) of its input does provide
>>>>>>>>>>>> the actual behavior of this input also rejects the notion of
>>>>>>>>>>>> a UTM which you accept, thus you (and all others holding
>>>>>>>>>>>> this view such as Ben) contradict yourself (themselves).
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So, why do you reject the actual correct and complete
>>>>>>>>>>> simulation of the input to H when done by an actual pure
>>>>>>>>>>> simulator/UTM?
>>>>>>>>>>>
>>>>>>>>>> As long as it is done at the exact point in the execution
>>>>>>>>>> trace as H(P,P) then it is fine, otherwise it is not the same
>>>>>>>>>> as the simulation by H(P,P).
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The simulation of the input to H(P,P) is the simulation of the
>>>>>>>>> instruction sequence specified by the code of P (and the
>>>>>>>>> routines it calls) and has ZERO dependency on what happened
>>>>>>>>> before that call
>>>>>>>>
>>>>>>>> main()
>>>>>>>> {
>>>>>>>>    P(P); // depends on the return value from H(P,P);
>>>>>>>> }
>>>>>>>>
>>>>>>>> The input to H(P,P) that H correctly simulates cannot possibly
>>>>>>>> depend on the return value from H because this return value is
>>>>>>>> unreachable by P:
>>>>>>>
>>>>>>> But it NEEDS to. That fact that it can't get the needed value
>>>>>>> because of the limitation of your algorithm, doesn't mean it gets
>>>>>>> to ignore it.
>>>>>>>
>>>>>>> Not, Mr Flibble has shown a way that H CAN determine the behavior
>>>>>>> of P based on the return value of H, even though H can simulate
>>>>>>> the path through itself.
>>>>>>>
>>>>>>> (As I pointed out a long time ago too).
>>>>>>
>>>>>> Every function that is called in infinite recursion cannot
>>>>>> possibly correctly return to its caller. People that believe that
>>>>>> it can are as wrong as if they disagreed with arithmetic.
>>>>>>
>>>>>> If computer science says that a function called in finite
>>>>>> recursion must return to its caller then computer science is
>>>>>> wrong, one might as well have said the cats must be dogs.
>>>>>>
>>>>>>>>
>>>>>>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>>>>>>>> (b) that simulates P(P) that calls a simulated H(P,P)
>>>>>>>> (c) that simulates P(P) that calls a simulated H(P,P)
>>>>>>>> (d) that simulates P(P) that calls a simulated H(P,P)...
>>>>>>>> *Until H aborts its simulation*
>>>>>>>>
>>>>>>>> This dependency difference causes the different behavior between
>>>>>>>> the simulated P and the executed P.
>>>>>>>
>>>>>>> Nope, the CORRECT AND COMPLETE simulation of the input does
>>>>>>> depend on the value that H(P,P) returns, unless H(P,P) never
>>>>>>> returns a value to ANYBODY.
>>>>>>>
>>>>>>> Your H just gets it wrong because it "guesses" wrong because it
>>>>>>> used unsound logic.
>>>>>>>
>>>>>>
>>>>>> You know that it did not merely guess.
>>>>>> You know that the correct and complete simulation by H(P,P) of its
>>>>>> input would never reach the final state of this input.
>>>>>
>>>>> No, that is a MEANINGLESS statement, because you H doesn't DO a
>>>>> complete simulation.
>>>>>
>>>>
>>>>
>>>> Do you know how ridiculously stupid it is of you of you to suggest
>>>> that a simulating halt decider perform a complete simulation of its
>>>> non-halting input?
>>>
>>> I never said it did. YOUR DEFINITION says it must,
>>
>>
>> *No knucklehead I never said anything like that, here is what I said*
>>
>> It is common knowledge that the correct and complete simulation of a
>> machine description always provides the actual behavior specified by
>> this machine description.
>
> Right.
>>
>> When-so-ever a simulating halt decider (SHD) correctly performs a
>> partial simulation of its input and the behavior of this partial
>> simulation correctly matches a correct non-halting behavior pattern
>> then the SHD halt decider can correctly report non-halting.
>
> Right, CORRECTLY match a CORRECT non-halting behavior pattern.
>
>>
>> A non-halting behavior pattern is correct when-so-ever matching this
>> behavior pattern proves that the correct and complete simulation of
>> the input by SHD would never reach the final state of this simulated
>> input.
>>
>
> INVALID.