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.

THe H that does try to argue that it is correct in aborting it
simulation doesn't actually do a correct and complete simulation, so has
made your criteria invalid. It is a different program, having a
different specific implementation than the one in the previous
paragraph, so the P that it is analyzing, that is calling IT, and not
the H from above isn't being correctly analyised when H presumes it is
calling that above H.

Thus, it is WRONG.

>
>>> Now the opinions diverge.
>>> Olcott thinks that his H gives the correct answer that P would not
>>> halt when P would call the hypothetical non-aborting H, so, it must
>>> also be the correct answer when P actually calls the actual aborting H.
>>>
>>> Others have a different opinion and argue that P does not call the
>>> hypothetical non-aborting H, but the actual aborting H, which does
>>> not go in infinite recursion, but returns false in a finite number of
>>> steps. Therefore, H's result is wrong.
>>>
>>> Is this a correct summary of the disagreement? If not, please, tell
>>> me where the summary failed. Maybe we can then find the point of
>>> divergence of opinions easier.
>>
>> Basically the disagreement is about the meaning of "correct".
>>
>> Mikko
>>
>
>

On 8/21/2022 12:08 PM, Shvili, the Kookologist wrote:
> [Re-post: line wrapping went haywire!]
>
> 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.
>
>

If you want to get nit-picky and define a final state as something other
than the last instruction of a sequence of instructions then:

When we define a halt state as any state where there are no transitions
on the current input and current state then the correct and complete
simulation by H(P,P) of its input never enters a halt state of this
simulated input.

void P(ptr x)
{ int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
__asm hlt
}

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 8/21/22 9:12 AM, Mikko wrote:
> On 2022-08-21 11:35:09 +0000, Richard Damon said:
>
>> On 8/21/22 5:08 AM, Mikko wrote:
>>> On 2022-08-20 20:00:31 +0000, Fred. Zwarts said:
>>>
>>>> Op 20.aug..2022 om 17:23 schreef olcott:
>>>
>>>>> *You did a very good job summing this up*
>>>>> The key nuance of divergence is that halting means that when H(P,P)
>>>>> correctly simulates its input that this input would reach the
>>>>> "return" instruction (final state) of P. H(P,P) correctly
>>>>> determines that its correct simulation of its input would never
>>>>> reach the "return" instruction of P.
>>>>>
>>>>
>>>> Thanks for the confirmation, because I was not completely sure about
>>>> my last sentence above. But I am glad that I understood you
>>>> correctly that your aborting H answers the question for P calling
>>>> the hypothetical non-aborting H.
>>>>
>>>> You derive the final answer (for P calling the actual aborting H)
>>>> indirectly from the first answer, because it cannot be answered
>>>> directly, as it would not reach the return instruction.
>>>
>>> Note that reaching return instruction is not the same as halting as
>>> specified in the original problem. Halting as required to be determined
>>> in the halting problem means that the computation as arrived to a any
>>> situation where the program does not specify the next action. The
>>> classical
>>> problem statement is about Turing machines where "return" is not
>>> defined.
>>>
>>> Mikko
>>>
>>
>> Actually, a "fanal return", where the initial function that performs
>> the computation returns to "its caller" is not a bad equivalent the
>> the halting state of a Turing Machine.
>
> No, but a program may terminate otherwise, e.g. throw an exception or
> call exit. Only if we know that a program does not terminate otherwise
> we may equate final return to halt.
>
> Mikko
>

A "Program" that doesn't give its "answer" to its "Caller" isn't
actually a computation.

a call to exit() is only an answer if done as part of the "whole
program" at which it is the program returning an answer to the
"Operating System"

A sub-function called a a function in a program that exits like this,
makes its sub-function not-a-computation.

Throwing an exection is really just a special form of return with just a
change of the default from the caller needing to handle the return
value, to the caller being able to just default to passing that return
value it its caller.

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.
>

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.

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.

H0(Infinite_Loop) H(Infinite_Recursion, 0x777) and H(P,P) all do this
correctly.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

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.

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 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.

Nope. That is your problem. Since you SHD, with the pattern installed
NEVER DOES a correct and complete sikmulation, that definition is
invalid as it is asking about the behavior of something that never happened.

What color shoe did Napolean walk on Mars with?

What you do is change the input program to do the test.

If you want to use a criteria like that you need to define your H as
taking 3 parameters, the program, its data, and a flag if you are doing
a halt decision or just a pure simulation.

P(x) call H(x,x,decide)

H needs to answer H(p,x,decide) return 1 if H(p,x,simulate) halts in
finite time, and return 0 if H(p,x,simulate) would never halt after an
unbounded number of steps.

That way you don't change the input when you ask if it would never halt
if not aborted.

Of course, you don't do that, because is shows that you H is wrong, as
P(P) WILL HALT, as show by H(P,P,simulate) halting if H(P,P,decide)
return 0, showing that is an incorrect answer.

>
> H0(Infinite_Loop) H(Infinite_Recursion, 0x777) and H(P,P) all do this
> correctly.
>

So, RED HERRING. proof you don't know how to do logic.

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).

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*

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

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).
>

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, and if it doesn't, then the input never matched the pattern and H
fails to answer.

The key is that that ACTUAL correct simulation of that input would then be:

(@) Simulate(P,P) simulates P(P) that calls a simulated H(P,P)
(a) that 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 the H simulated in step (@) aborts its simulation*
(e) That simulated H returns 0 to the simulate P(P) in (@)
(f) That simulated P(P) returns and thus halts.

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

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:

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,

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).

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.

> 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

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!

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).

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:

(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.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 8/22/2022 10: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?
>

Does the finite string input SPECIFY a sequence of INSTRUCTIONS 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!
>
> 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).
>
> 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:
>
> (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.
>
>
>

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

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.

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
>

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*

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
>

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.

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
>
>