On 7/9/2021 9:39 PM, André G. Isaak wrote:
> On 2021-07-09 17:31, olcott wrote:
>> On 7/9/2021 6:23 PM, Ben Bacarisse wrote:
>
>>> P(P) halts.  If you don't "count" all halting computations as halting
>>> you are talking nonsense.
>>>
>>
>> A computation that stops running because it has been aborted is as
>> Richard put it suspended, and not halted.
>
> Yes, but when P(P) is run independently there is nothing which can
> suspend this computation because it isn't being run in a simulator.
>

What everyone consistently ignores is that only the prefix of the
computation runs independently. If the suffix of this computation was
not aborted then P(P) would never halt.

Simulating halt decider H is only answering the question:
Would the input halt on its input if H never stopped simulating it?
(a) An answer of "no" universally means that the input never halts.
(b) An answer of "yes" universally means that the input halts.

Halt Deciding Axiom: When the pure simulation of the machine description
⟨P⟩ of a machine P on its input I never halts we know that P(I) never
halts.

> In this case, the outermost P is the computation which is being
> performed and acts as the simulator. The innermost P is the input which
> is being simulated. The inner P might get suspended by the outer P, but
> the outer P can't be suspended. It simply *halts*.
>
> André
>
>

No P ever halts unless some P is aborted, thus P(P) is accurately
construed as specifying infinitely nested simulation.

--
Copyright 2021 Pete Olcott

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

On 7/9/2021 10:46 PM, André G. Isaak wrote:
> On 2021-07-09 21:18, olcott wrote:
>> On 7/9/2021 9:39 PM, André G. Isaak wrote:
>>> On 2021-07-09 17:31, olcott wrote:
>>>> On 7/9/2021 6:23 PM, Ben Bacarisse wrote:
>>>
>>>>> P(P) halts.  If you don't "count" all halting computations as halting
>>>>> you are talking nonsense.
>>>>>
>>>>
>>>> A computation that stops running because it has been aborted is as
>>>> Richard put it suspended, and not halted.
>>>
>>> Yes, but when P(P) is run independently there is nothing which can
>>> suspend this computation because it isn't being run in a simulator.
>>>
>>
>> What everyone consistently ignores is that only the prefix of the
>> computation runs independently. If the suffix of this computation was
>> not aborted then P(P) would never halt.
>
> Computations don't have 'prefixes' or 'suffixes'. P(P) represents a
> single computation.
>
>> Simulating halt decider H is only answering the question:
>> Would the input halt on its input if H never stopped simulating it?
>
> When we run P(P) independently it isn't being run inside of H so the
> above question is meaningless. If P(P) halts, then it halts. If not, it
> doesn't. Whatever H might have to say about it is irrelevant.
>
>> (a) An answer of "no" universally means that the input never halts.
>> (b) An answer of "yes" universally means that the input halts.
>>
>> Halt Deciding Axiom: When the pure simulation of the machine
>> description ⟨P⟩ of a machine P on its input I never halts we know that
>> P(I) never halts.
>
> You really need to learn what 'axioms' are.
>
> If the above is provable from existing tenets of computational theory,
> then it has no business being called an axiom.
>
> If it isn't, and you're introducing something new as an axiom, then
> you're no longer talking about the same computational theory that the
> halting problem is part of.
>

The above axiom is provided by the definition of a UTM, thus neither
provable nor something new. It is like all axioms a stipulated definition.

>>> In this case, the outermost P is the computation which is being
>>> performed and acts as the simulator. The innermost P is the input
>>> which is being simulated. The inner P might get suspended by the
>>> outer P, but the outer P can't be suspended. It simply *halts*.
>>>
>>> André
>>>
>>>
>>
>> No P ever halts unless some P is aborted, thus P(P) is accurately
>> construed as specifying infinitely nested simulation.
>
>
> But when we ask whether P(P) halts, we're asking specifically about the
> computation P(P). We're not asking about 'some P'.
>
> André
>

P(P) specifies an infinite set of nested simulations that never halts
unless one of the invocations of this infinite chain is aborted, thus
proving that it really does specify an infinite set of nested simulations.

--
Copyright 2021 Pete Olcott

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

On 7/9/2021 11:28 PM, André G. Isaak wrote:
> On 2021-07-09 22:01, olcott wrote:
>> On 7/9/2021 10:46 PM, André G. Isaak wrote:
>>> On 2021-07-09 21:18, olcott wrote:
>>>> On 7/9/2021 9:39 PM, André G. Isaak wrote:
>>>>> On 2021-07-09 17:31, olcott wrote:
>>>>>> On 7/9/2021 6:23 PM, Ben Bacarisse wrote:
>>>>>
>>>>>>> P(P) halts.  If you don't "count" all halting computations as
>>>>>>> halting
>>>>>>> you are talking nonsense.
>>>>>>>
>>>>>>
>>>>>> A computation that stops running because it has been aborted is as
>>>>>> Richard put it suspended, and not halted.
>>>>>
>>>>> Yes, but when P(P) is run independently there is nothing which can
>>>>> suspend this computation because it isn't being run in a simulator.
>>>>>
>>>>
>>>> What everyone consistently ignores is that only the prefix of the
>>>> computation runs independently. If the suffix of this computation
>>>> was not aborted then P(P) would never halt.
>>>
>>> Computations don't have 'prefixes' or 'suffixes'. P(P) represents a
>>> single computation.
>>>
>>>> Simulating halt decider H is only answering the question:
>>>> Would the input halt on its input if H never stopped simulating it?
>>>
>>> When we run P(P) independently it isn't being run inside of H so the
>>> above question is meaningless. If P(P) halts, then it halts. If not,
>>> it doesn't. Whatever H might have to say about it is irrelevant.
>>>
>>>> (a) An answer of "no" universally means that the input never halts.
>>>> (b) An answer of "yes" universally means that the input halts.
>>>>
>>>> Halt Deciding Axiom: When the pure simulation of the machine
>>>> description ⟨P⟩ of a machine P on its input I never halts we know
>>>> that P(I) never halts.
>>>
>>> You really need to learn what 'axioms' are.
>>>
>>> If the above is provable from existing tenets of computational
>>> theory, then it has no business being called an axiom.
>>>
>>> If it isn't, and you're introducing something new as an axiom, then
>>> you're no longer talking about the same computational theory that the
>>> halting problem is part of.
>>>
>>
>> The above axiom is provided by the definition of a UTM, thus neither
>> provable nor something new. It is like all axioms a stipulated
>> definition.
>
> As I said, you really need to learn what 'axioms' are.
>
>>>>> In this case, the outermost P is the computation which is being
>>>>> performed and acts as the simulator. The innermost P is the input
>>>>> which is being simulated. The inner P might get suspended by the
>>>>> outer P, but the outer P can't be suspended. It simply *halts*.
>>>>>
>>>>> André
>>>>>
>>>>>
>>>>
>>>> No P ever halts unless some P is aborted, thus P(P) is accurately
>>>> construed as specifying infinitely nested simulation.
>>>
>>>
>>> But when we ask whether P(P) halts, we're asking specifically about
>>> the computation P(P). We're not asking about 'some P'.
>>>
>>> André
>>>
>>
>> P(P) specifies an infinite set of nested simulations that never halts
>> unless one of the invocations of this infinite chain is aborted, thus
>> proving that it really does specify an infinite set of nested
>> simulations.
>
> But by virtue of the way P is written, one of the nested simulations in
> P(P) is *always* aborted. Ergo the computation itself always halts.
>

When one of the function calls of infinite recursion is aborted the
infinite recursion also stops running but this does not count as halting
because the only reason that any of it ever stopped running is that one
of the links of the infinite recursion chain was aborted.

It is the same thing with infinitely nested simulation.

> As soon as you talk about a case where none of these simulations are
> aborted, you are no longer talking about P(P). You are talking about
> some other computation.

P(P) specifies an infinite chain of nested simulations. When you see its
execution trace this becomes obvious.

> The halting status of that other computation is
> entirely irrelevant to the halting status of P(P).

P(P) specifies an infinite chain of nested simulations. When you see its
execution trace this becomes obvious.

> And absolutely nothing in your post has anything to do with the C or
> software engineering, let alone the philosophy of AI. Those groups
> simply do not belong.
>
> André
>

--
Copyright 2021 Pete Olcott

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

On 7/10/2021 12:24 AM, André G. Isaak wrote:
> On 2021-07-09 22:45, olcott wrote:
>> On 7/9/2021 11:28 PM, André G. Isaak wrote:
>
>>> But by virtue of the way P is written, one of the nested simulations
>>> in P(P) is *always* aborted. Ergo the computation itself always halts.
>>>
>>
>> When one of the function calls of infinite recursion is aborted the
>> infinite recursion also stops running but this does not count as
>> halting because the only reason that any of it ever stopped running is
>> that one of the links of the infinite recursion chain was aborted.
>>
>> It is the same thing with infinitely nested simulation.
>
> Except that the topmost P, which is the one we are interested in,
> *isn't* a simulation. It is the thing doing the simulating and it isn't
> part of your chain of 'infinitely nested simulations'.
>

Every H in the nested simulations of P(P) only acts as a pure simulator
on its input until after it makes its halt status decision.

This means that every H Every H in the nested simulations of P(P) can
always screen out its own entire address range when examining the
execution trace of its input.

_P()
[00000b1a](01) 55 push ebp
[00000b1b](02) 8bec mov ebp,esp
[00000b1d](01) 51 push ecx
[00000b1e](03) 8b4508 mov eax,[ebp+08]
[00000b21](01) 50 push eax // 2nd Param
[00000b22](03) 8b4d08 mov ecx,[ebp+08]
[00000b25](01) 51 push ecx // 1st Param
[00000b26](05) e81ffeffff call 0000094a // call H

Begin Local Halt Decider Simulation at Machine Address:b1a
[00000b1a][002116e7][002116eb] 55 push ebp
[00000b1b][002116e7][002116eb] 8bec mov ebp,esp
[00000b1d][002116e3][002016b7] 51 push ecx
[00000b1e][002116e3][002016b7] 8b4508 mov eax,[ebp+08]
[00000b21][002116df][00000b1a] 50 push eax // push P
[00000b22][002116df][00000b1a] 8b4d08 mov ecx,[ebp+08]
[00000b25][002116db][00000b1a] 51 push ecx // push P
[00000b26][002116d7][00000b2b] e81ffeffff call 0000094a // call H
[00000b1a][0025c10f][0025c113] 55 push ebp
[00000b1b][0025c10f][0025c113] 8bec mov ebp,esp
[00000b1d][0025c10b][0024c0df] 51 push ecx
[00000b1e][0025c10b][0024c0df] 8b4508 mov eax,[ebp+08]
[00000b21][0025c107][00000b1a] 50 push eax // push P
[00000b22][0025c107][00000b1a] 8b4d08 mov ecx,[ebp+08]
[00000b25][0025c103][00000b1a] 51 push ecx // push P
[00000b26][0025c0ff][00000b2b] e81ffeffff call 0000094a // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

This means the the above execution trace of P(P) determines that P(P)
never halts. P is stuck in infinitely nested simulation calling H(P,P)
which simulates P(P) which calls H(P,P)...

> As I pointed out in an earlier post, given some simulator which has the
> ability to stop simulating its inputs under certain circumstances, there
> are only three logical possibilities:
>
> (1) The simulated computation continues until it reaches a final state.
>
> (2) The simulator decides to stop the simulation at some point.
>
> (3) The simulated computation is allowed to continue forever and is not
> aborted.
>
> In both cases (1) and (2) the SIMULATOR halts. The fact that the input
> never reaches its end in (2) isn't relevant to this fact regardless of
> whether the input is or is not a halting computation.
>

As Richard aptly put it a computation that has had its simulation
aborted does not count as a computation that halts. Its computation has
been suspended. That the simulating halt decider halts has no bearing on
whether or not its input is a halting computation.

Richard seems to understand this one point better than you do.

> Only in case (3) does the simulator not halt.
>
> [The last time I pointed this out you complained that I didn't mention
> your 'halting criterion'. I don't mention it because the above applies
> to *any* simulator which has the ability to discontinue its simulation,
> not just your H. But it applies equally to your H.]
>
>>> As soon as you talk about a case where none of these simulations are
>>> aborted, you are no longer talking about P(P). You are talking about
>>> some other computation.
>>
>> P(P) specifies an infinite chain of nested simulations. When you see
>> its execution trace this becomes obvious.
>>
>>> The halting status of that other computation is entirely irrelevant
>>> to the halting status of P(P).
>>
>> P(P) specifies an infinite chain of nested simulations. When you see
>> its execution trace this becomes obvious.
>
> No. It doesn't. P(P) is guaranteed to stop simulating at the second
> level of simulation. It never gets to any levels beyond that, ergo it is
> not an infinite chain of nested simulations. It is a two-deep chain of
> simulations.
>
> André
>

--
Copyright 2021 Pete Olcott

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

On 7/10/2021 9:30 AM, Mr Flibble wrote:
> On Sat, 10 Jul 2021 08:54:23 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 7/10/2021 6:40 AM, Mr Flibble wrote:
>>> On Fri, 9 Jul 2021 16:13:48 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 7/9/2021 4:08 PM, Mr Flibble wrote:
>>>>> On Fri, 9 Jul 2021 14:24:33 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 7/9/2021 2:16 PM, Mr Flibble wrote:
>>>>>>> On Fri, 9 Jul 2021 12:47:12 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> On 7/9/2021 12:06 PM, Mr Flibble wrote:
>>>>>>>>> On Fri, 9 Jul 2021 08:59:51 -0500
>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>> [Halt Deciding Axiom] When the pure simulation of the machine
>>>>>>>>>> description ⟨P⟩ of a machine P on its input I never halts we
>>>>>>>>>> know that P(I) never halts.
>>>>>>>>>>
>>>>>>>>>> No we cannot. In order to remove the pathological feedback
>>>>>>>>>> loop such that P does the opposite of whatever H decides H
>>>>>>>>>> simply acts as a pure simulator of P thus having no effect
>>>>>>>>>> what-so-ever on the behavior of P until after its halt status
>>>>>>>>>> decision has been made.
>>>>>>>>>
>>>>>>>>> Except your decider can only handle trivial uninteresting
>>>>>>>>> cases: if you wish to make progress on this then prove your
>>>>>>>>> decider works with a non-trivial case which includes
>>>>>>>>> branching logic predicated on arbitrary program input that is
>>>>>>>>> unknown a priori to the simulation starting; but before you
>>>>>>>>> even do that prove your decider works with a non-trivial case
>>>>>>>>> with branching logic predicated on arbitrary program input
>>>>>>>>> that *is* known a priori.
>>>>>>>>
>>>>>>>> You continue to prove to everyone that actually knows these
>>>>>>>> things that you are an ignoramus on this subject.
>>>>>>>>
>>>>>>>> That H correctly decides that all of the standard
>>>>>>>> counter-examples templates never halt eliminates the entire
>>>>>>>> basis of all of the conventional halting problem undecidability
>>>>>>>> proofs.
>>>>>>>>> I also note that you repeatedly refuse to address my point
>>>>>>>>> regarding how x86 mov instructions can read/write from/to
>>>>>>>>> memory mapped I/O rather than RAM so the result of the mov
>>>>>>>>> instruction cannot be known a priori. The halting program
>>>>>>>>> concerns computing devices and a computing device which
>>>>>>>>> cannot do I/O is next to useless, much like your decider
>>>>>>>>> (until you actually prove otherwise which I have a feeling is
>>>>>>>>> never going to happen as you appear to be stuck in a loop).
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> I continue to note that you repeatedly refuse to address my
>>>>>>> point regarding how x86 mov instructions can read/write from/to
>>>>>>> memory mapped I/O rather than RAM so the result of the mov
>>>>>>> instruction cannot be known a priori. The halting program
>>>>>>> concerns computing devices and a computing device which cannot
>>>>>>> do I/O is next to useless, much like your decider (until you
>>>>>>> actually prove otherwise which I have a feeling is never going
>>>>>>> to happen as you appear to be stuck in a loop).
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> You are the only one that believes that your points have any
>>>>>> relevance. That you believe that data movement instructions have
>>>>>> anything to do with control flow proves that your points have no
>>>>>> relevance.
>>>>>
>>>>> You literally have no clue about what you are talking about,
>>>>> whatsoever. This explains everything.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> *Make sure that you read all of this especially the last line*
>>>>
>>>> halt (p, i)
>>>> {
>>>> if ( program p halts on input i )
>>>> return true ; // p halts
>>>> else
>>>> return false ; // p doesn’t halt
>>>> }
>>>> Fig. 1. Pseudocode of the Halting Function
>>>>
>>>> Strachey’s Impossible Program Strachey proposed a program
>>>> based on the result of an assumed halting function [2].
>>>> The way Strachey’s construction and other similar constructions
>>>> are used to show the impossibility of a decideable halting
>>>> function is quite similar to Turing’s original disproof.
>>>> But the relevant difference we want to emphasize is that
>>>> they do not explicitly assume an infinite number of possible
>>>> machines (programs) or input data, because they directly use
>>>> reductio ad absurdum to prove that both, Strachey’s construction
>>>> and the universal halting function cannot exist.
>>>>
>>>> strachey ( p )
>>>> {
>>>> if ( halt (p, p) == true )
>>>> L1 : goto L1 ; // loop forever
>>>> else
>>>> return;
>>>> }
>>>>
>>>> Fig. 2. Strachey’s Impossible Program
>>>>
>>>> The impossibility of Strachey’s construction given in Figure 2
>>>> becomes obvious if one tries to apply the halting function as
>>>> follows:
>>>>
>>>> halt(strachey, strachey)
>>>>
>>>> Since in this case strachey() itself calls halt(strachey,
>>>> strachey), it is required that the direct call of halt() and the
>>>> nested call provide the same result. However, this leads to a
>>>> contradiction, whatever result halt() returns. Within this
>>>> disproof there seems to be no indication why not it could be even
>>>> applied to finite-state systems having a concrete upper bound of
>>>> state space.
>>>>
>>>> https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.206.1468&rep=rep1&type=pdf
>>>>
>>>
>>> Except your decider can only handle trivial uninteresting cases: if
>>> you
>>
>> Ask other people here if being able to correctly decide the strachey
>> case is trivial or uninteresting. Ben might be the best one to ask
>> about this.
>>
>> Here is his original 1965 letter.
>> https://academic.oup.com/comjnl/article/7/4/313/354243
>
> All Strachey's letter shows is that a decider cannot be part of
> that which is being decided.
>
> /Flibble
>

// Simplified Linz Ĥ (Linz:1990:319)
void P(u32 x)
{ u32 Input_Halts = H(x, x);
if (Input_Halts)
HERE: goto HERE;
}

int main()
{ u32 Input_Halts = H((u32)P, (u32)P);
Output("Input_Halts = ", Input_Halts);
}

What it shows is that the halting problem proof can be enormously
simplified to the impossibility of the H(P,P) in main() returning a
correct halt status value to main().

*Here are Strachey's (verbatim) own words*
Suppose T[R] is a Boolean function taking a routine
(or program) R with no formal or free variables as its
argument and that for all R, T[R] — True if R terminates
if run and that T[R] = False if R does not terminate.
Consider the routine P defined as follows

On Sat, 10 Jul 2021 10:00:51 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/10/2021 9:30 AM, Mr Flibble wrote:
> > On Sat, 10 Jul 2021 08:54:23 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 7/10/2021 6:40 AM, Mr Flibble wrote:
> >>> On Fri, 9 Jul 2021 16:13:48 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 7/9/2021 4:08 PM, Mr Flibble wrote:
> >>>>> On Fri, 9 Jul 2021 14:24:33 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> On 7/9/2021 2:16 PM, Mr Flibble wrote:
> >>>>>>> On Fri, 9 Jul 2021 12:47:12 -0500
> >>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>
> >>>>>>>> On 7/9/2021 12:06 PM, Mr Flibble wrote:
> >>>>>>>>> On Fri, 9 Jul 2021 08:59:51 -0500
> >>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>> [Halt Deciding Axiom] When the pure simulation of the
> >>>>>>>>>> machine description ⟨P⟩ of a machine P on its input I
> >>>>>>>>>> never halts we know that P(I) never halts.
> >>>>>>>>>>
> >>>>>>>>>> No we cannot. In order to remove the pathological feedback
> >>>>>>>>>> loop such that P does the opposite of whatever H decides H
> >>>>>>>>>> simply acts as a pure simulator of P thus having no effect
> >>>>>>>>>> what-so-ever on the behavior of P until after its halt
> >>>>>>>>>> status decision has been made.
> >>>>>>>>>
> >>>>>>>>> Except your decider can only handle trivial uninteresting
> >>>>>>>>> cases: if you wish to make progress on this then prove your
> >>>>>>>>> decider works with a non-trivial case which includes
> >>>>>>>>> branching logic predicated on arbitrary program input that
> >>>>>>>>> is unknown a priori to the simulation starting; but before
> >>>>>>>>> you even do that prove your decider works with a
> >>>>>>>>> non-trivial case with branching logic predicated on
> >>>>>>>>> arbitrary program input that *is* known a priori.
> >>>>>>>>
> >>>>>>>> You continue to prove to everyone that actually knows these
> >>>>>>>> things that you are an ignoramus on this subject.
> >>>>>>>>
> >>>>>>>> That H correctly decides that all of the standard
> >>>>>>>> counter-examples templates never halt eliminates the entire
> >>>>>>>> basis of all of the conventional halting problem
> >>>>>>>> undecidability proofs.
> >>>>>>>>> I also note that you repeatedly refuse to address my point
> >>>>>>>>> regarding how x86 mov instructions can read/write from/to
> >>>>>>>>> memory mapped I/O rather than RAM so the result of the mov
> >>>>>>>>> instruction cannot be known a priori. The halting program
> >>>>>>>>> concerns computing devices and a computing device which
> >>>>>>>>> cannot do I/O is next to useless, much like your decider
> >>>>>>>>> (until you actually prove otherwise which I have a feeling
> >>>>>>>>> is never going to happen as you appear to be stuck in a
> >>>>>>>>> loop).
> >>>>>>>>>
> >>>>>>>>> /Flibble
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> I continue to note that you repeatedly refuse to address my
> >>>>>>> point regarding how x86 mov instructions can read/write
> >>>>>>> from/to memory mapped I/O rather than RAM so the result of
> >>>>>>> the mov instruction cannot be known a priori. The halting
> >>>>>>> program concerns computing devices and a computing device
> >>>>>>> which cannot do I/O is next to useless, much like your
> >>>>>>> decider (until you actually prove otherwise which I have a
> >>>>>>> feeling is never going to happen as you appear to be stuck in
> >>>>>>> a loop).
> >>>>>>>
> >>>>>>> /Flibble
> >>>>>>>
> >>>>>>
> >>>>>> You are the only one that believes that your points have any
> >>>>>> relevance. That you believe that data movement instructions
> >>>>>> have anything to do with control flow proves that your points
> >>>>>> have no relevance.
> >>>>>
> >>>>> You literally have no clue about what you are talking about,
> >>>>> whatsoever. This explains everything.
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>
> >>>> *Make sure that you read all of this especially the last line*
> >>>>
> >>>> halt (p, i)
> >>>> {
> >>>> if ( program p halts on input i )
> >>>> return true ; // p halts
> >>>> else
> >>>> return false ; // p doesn’t halt
> >>>> }
> >>>> Fig. 1. Pseudocode of the Halting Function
> >>>>
> >>>> Strachey’s Impossible Program Strachey proposed a program
> >>>> based on the result of an assumed halting function [2].
> >>>> The way Strachey’s construction and other similar constructions
> >>>> are used to show the impossibility of a decideable halting
> >>>> function is quite similar to Turing’s original disproof.
> >>>> But the relevant difference we want to emphasize is that
> >>>> they do not explicitly assume an infinite number of possible
> >>>> machines (programs) or input data, because they directly use
> >>>> reductio ad absurdum to prove that both, Strachey’s construction
> >>>> and the universal halting function cannot exist.
> >>>>
> >>>> strachey ( p )
> >>>> {
> >>>> if ( halt (p, p) == true )
> >>>> L1 : goto L1 ; // loop forever
> >>>> else
> >>>> return;
> >>>> }
> >>>>
> >>>> Fig. 2. Strachey’s Impossible Program
> >>>>
> >>>> The impossibility of Strachey’s construction given in Figure 2
> >>>> becomes obvious if one tries to apply the halting function as
> >>>> follows:
> >>>>
> >>>> halt(strachey, strachey)
> >>>>
> >>>> Since in this case strachey() itself calls halt(strachey,
> >>>> strachey), it is required that the direct call of halt() and the
> >>>> nested call provide the same result. However, this leads to a
> >>>> contradiction, whatever result halt() returns. Within this
> >>>> disproof there seems to be no indication why not it could be even
> >>>> applied to finite-state systems having a concrete upper bound of
> >>>> state space.
> >>>>
> >>>> https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.206.1468&rep=rep1&type=pdf
> >>>>
> >>>
> >>> Except your decider can only handle trivial uninteresting cases:
> >>> if you
> >>
> >> Ask other people here if being able to correctly decide the
> >> strachey case is trivial or uninteresting. Ben might be the best
> >> one to ask about this.
> >>
> >> Here is his original 1965 letter.
> >> https://academic.oup.com/comjnl/article/7/4/313/354243
> >
> > All Strachey's letter shows is that a decider cannot be part of
> > that which is being decided.
> >
> > /Flibble
> >
>
>
> // Simplified Linz Ĥ (Linz:1990:319)
> void P(u32 x)
> {
> u32 Input_Halts = H(x, x);
> if (Input_Halts)
> HERE: goto HERE;
> }
>
> int main()
> {
> u32 Input_Halts = H((u32)P, (u32)P);
> Output("Input_Halts = ", Input_Halts);
> }
>
> What it shows is that the halting problem proof can be enormously
> simplified to the impossibility of the H(P,P) in main() returning a
> correct halt status value to main().
>
> *Here are Strachey's (verbatim) own words*
> Suppose T[R] is a Boolean function taking a routine
> (or program) R with no formal or free variables as its
> argument and that for all R, T[R] — True if R terminates
> if run and that T[R] = False if R does not terminate.
> Consider the routine P defined as follows
>
> rec routine P
> §L:if T[P] go to L
> Return §
>
> If T[P] = True the routine P will loop, and it will
> only terminate if T[P] = False. In each case T[P] has
> exactly the wrong value, and this contradiction shows
> that the function T cannot exist.
>
> Strachey is the creator of CPL ancestor to BCPL then B then C
> His code above is written in his CPL programming language.

On 7/10/2021 10:15 AM, Mr Flibble wrote:
> On Sat, 10 Jul 2021 10:00:51 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 7/10/2021 9:30 AM, Mr Flibble wrote:
>>> On Sat, 10 Jul 2021 08:54:23 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 7/10/2021 6:40 AM, Mr Flibble wrote:
>>>>> On Fri, 9 Jul 2021 16:13:48 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 7/9/2021 4:08 PM, Mr Flibble wrote:
>>>>>>> On Fri, 9 Jul 2021 14:24:33 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> On 7/9/2021 2:16 PM, Mr Flibble wrote:
>>>>>>>>> On Fri, 9 Jul 2021 12:47:12 -0500
>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 7/9/2021 12:06 PM, Mr Flibble wrote:
>>>>>>>>>>> On Fri, 9 Jul 2021 08:59:51 -0500
>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>> [Halt Deciding Axiom] When the pure simulation of the
>>>>>>>>>>>> machine description ⟨P⟩ of a machine P on its input I
>>>>>>>>>>>> never halts we know that P(I) never halts.
>>>>>>>>>>>>
>>>>>>>>>>>> No we cannot. In order to remove the pathological feedback
>>>>>>>>>>>> loop such that P does the opposite of whatever H decides H
>>>>>>>>>>>> simply acts as a pure simulator of P thus having no effect
>>>>>>>>>>>> what-so-ever on the behavior of P until after its halt
>>>>>>>>>>>> status decision has been made.
>>>>>>>>>>>
>>>>>>>>>>> Except your decider can only handle trivial uninteresting
>>>>>>>>>>> cases: if you wish to make progress on this then prove your
>>>>>>>>>>> decider works with a non-trivial case which includes
>>>>>>>>>>> branching logic predicated on arbitrary program input that
>>>>>>>>>>> is unknown a priori to the simulation starting; but before
>>>>>>>>>>> you even do that prove your decider works with a
>>>>>>>>>>> non-trivial case with branching logic predicated on
>>>>>>>>>>> arbitrary program input that *is* known a priori.
>>>>>>>>>>
>>>>>>>>>> You continue to prove to everyone that actually knows these
>>>>>>>>>> things that you are an ignoramus on this subject.
>>>>>>>>>>
>>>>>>>>>> That H correctly decides that all of the standard
>>>>>>>>>> counter-examples templates never halt eliminates the entire
>>>>>>>>>> basis of all of the conventional halting problem
>>>>>>>>>> undecidability proofs.
>>>>>>>>>>> I also note that you repeatedly refuse to address my point
>>>>>>>>>>> regarding how x86 mov instructions can read/write from/to
>>>>>>>>>>> memory mapped I/O rather than RAM so the result of the mov
>>>>>>>>>>> instruction cannot be known a priori. The halting program
>>>>>>>>>>> concerns computing devices and a computing device which
>>>>>>>>>>> cannot do I/O is next to useless, much like your decider
>>>>>>>>>>> (until you actually prove otherwise which I have a feeling
>>>>>>>>>>> is never going to happen as you appear to be stuck in a
>>>>>>>>>>> loop).
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I continue to note that you repeatedly refuse to address my
>>>>>>>>> point regarding how x86 mov instructions can read/write
>>>>>>>>> from/to memory mapped I/O rather than RAM so the result of
>>>>>>>>> the mov instruction cannot be known a priori. The halting
>>>>>>>>> program concerns computing devices and a computing device
>>>>>>>>> which cannot do I/O is next to useless, much like your
>>>>>>>>> decider (until you actually prove otherwise which I have a
>>>>>>>>> feeling is never going to happen as you appear to be stuck in
>>>>>>>>> a loop).
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>
>>>>>>>> You are the only one that believes that your points have any
>>>>>>>> relevance. That you believe that data movement instructions
>>>>>>>> have anything to do with control flow proves that your points
>>>>>>>> have no relevance.
>>>>>>>
>>>>>>> You literally have no clue about what you are talking about,
>>>>>>> whatsoever. This explains everything.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> *Make sure that you read all of this especially the last line*
>>>>>>
>>>>>> halt (p, i)
>>>>>> {
>>>>>> if ( program p halts on input i )
>>>>>> return true ; // p halts
>>>>>> else
>>>>>> return false ; // p doesn’t halt
>>>>>> }
>>>>>> Fig. 1. Pseudocode of the Halting Function
>>>>>>
>>>>>> Strachey’s Impossible Program Strachey proposed a program
>>>>>> based on the result of an assumed halting function [2].
>>>>>> The way Strachey’s construction and other similar constructions
>>>>>> are used to show the impossibility of a decideable halting
>>>>>> function is quite similar to Turing’s original disproof.
>>>>>> But the relevant difference we want to emphasize is that
>>>>>> they do not explicitly assume an infinite number of possible
>>>>>> machines (programs) or input data, because they directly use
>>>>>> reductio ad absurdum to prove that both, Strachey’s construction
>>>>>> and the universal halting function cannot exist.
>>>>>>
>>>>>> strachey ( p )
>>>>>> {
>>>>>> if ( halt (p, p) == true )
>>>>>> L1 : goto L1 ; // loop forever
>>>>>> else
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> Fig. 2. Strachey’s Impossible Program
>>>>>>
>>>>>> The impossibility of Strachey’s construction given in Figure 2
>>>>>> becomes obvious if one tries to apply the halting function as
>>>>>> follows:
>>>>>>
>>>>>> halt(strachey, strachey)
>>>>>>
>>>>>> Since in this case strachey() itself calls halt(strachey,
>>>>>> strachey), it is required that the direct call of halt() and the
>>>>>> nested call provide the same result. However, this leads to a
>>>>>> contradiction, whatever result halt() returns. Within this
>>>>>> disproof there seems to be no indication why not it could be even
>>>>>> applied to finite-state systems having a concrete upper bound of
>>>>>> state space.
>>>>>>
>>>>>> https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.206.1468&rep=rep1&type=pdf
>>>>>>
>>>>>
>>>>> Except your decider can only handle trivial uninteresting cases:
>>>>> if you
>>>>
>>>> Ask other people here if being able to correctly decide the
>>>> strachey case is trivial or uninteresting. Ben might be the best
>>>> one to ask about this.
>>>>
>>>> Here is his original 1965 letter.
>>>> https://academic.oup.com/comjnl/article/7/4/313/354243
>>>
>>> All Strachey's letter shows is that a decider cannot be part of
>>> that which is being decided.
>>>
>>> /Flibble
>>>
>>
>>
>> // Simplified Linz Ĥ (Linz:1990:319)
>> void P(u32 x)
>> {
>> u32 Input_Halts = H(x, x);
>> if (Input_Halts)
>> HERE: goto HERE;
>> }
>>
>> int main()
>> {
>> u32 Input_Halts = H((u32)P, (u32)P);
>> Output("Input_Halts = ", Input_Halts);
>> }
>>
>> What it shows is that the halting problem proof can be enormously
>> simplified to the impossibility of the H(P,P) in main() returning a
>> correct halt status value to main().
>>
>> *Here are Strachey's (verbatim) own words*
>> Suppose T[R] is a Boolean function taking a routine
>> (or program) R with no formal or free variables as its
>> argument and that for all R, T[R] — True if R terminates
>> if run and that T[R] = False if R does not terminate.
>> Consider the routine P defined as follows
>>
>> rec routine P
>> §L:if T[P] go to L
>> Return §
>>
>> If T[P] = True the routine P will loop, and it will
>> only terminate if T[P] = False. In each case T[P] has
>> exactly the wrong value, and this contradiction shows
>> that the function T cannot exist.
>>
>> Strachey is the creator of CPL ancestor to BCPL then B then C
>> His code above is written in his CPL programming language.
>
> I repeat: all Strachey's letter shows is that a decider cannot be part
> of that which is being decided.
>
> /Flibble
>

On Sat, 10 Jul 2021 10:21:26 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/10/2021 10:15 AM, Mr Flibble wrote:
> > On Sat, 10 Jul 2021 10:00:51 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 7/10/2021 9:30 AM, Mr Flibble wrote:
> >>> On Sat, 10 Jul 2021 08:54:23 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 7/10/2021 6:40 AM, Mr Flibble wrote:
> >>>>> On Fri, 9 Jul 2021 16:13:48 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> On 7/9/2021 4:08 PM, Mr Flibble wrote:
> >>>>>>> On Fri, 9 Jul 2021 14:24:33 -0500
> >>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>
> >>>>>>>> On 7/9/2021 2:16 PM, Mr Flibble wrote:
> >>>>>>>>> On Fri, 9 Jul 2021 12:47:12 -0500
> >>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> On 7/9/2021 12:06 PM, Mr Flibble wrote:
> >>>>>>>>>>> On Fri, 9 Jul 2021 08:59:51 -0500
> >>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>> [Halt Deciding Axiom] When the pure simulation of the
> >>>>>>>>>>>> machine description ⟨P⟩ of a machine P on its input I
> >>>>>>>>>>>> never halts we know that P(I) never halts.
> >>>>>>>>>>>>
> >>>>>>>>>>>> No we cannot. In order to remove the pathological
> >>>>>>>>>>>> feedback loop such that P does the opposite of whatever
> >>>>>>>>>>>> H decides H simply acts as a pure simulator of P thus
> >>>>>>>>>>>> having no effect what-so-ever on the behavior of P until
> >>>>>>>>>>>> after its halt status decision has been made.
> >>>>>>>>>>>
> >>>>>>>>>>> Except your decider can only handle trivial uninteresting
> >>>>>>>>>>> cases: if you wish to make progress on this then prove
> >>>>>>>>>>> your decider works with a non-trivial case which includes
> >>>>>>>>>>> branching logic predicated on arbitrary program input that
> >>>>>>>>>>> is unknown a priori to the simulation starting; but before
> >>>>>>>>>>> you even do that prove your decider works with a
> >>>>>>>>>>> non-trivial case with branching logic predicated on
> >>>>>>>>>>> arbitrary program input that *is* known a priori.
> >>>>>>>>>>
> >>>>>>>>>> You continue to prove to everyone that actually knows these
> >>>>>>>>>> things that you are an ignoramus on this subject.
> >>>>>>>>>>
> >>>>>>>>>> That H correctly decides that all of the standard
> >>>>>>>>>> counter-examples templates never halt eliminates the entire
> >>>>>>>>>> basis of all of the conventional halting problem
> >>>>>>>>>> undecidability proofs.
> >>>>>>>>>>> I also note that you repeatedly refuse to address my point
> >>>>>>>>>>> regarding how x86 mov instructions can read/write from/to
> >>>>>>>>>>> memory mapped I/O rather than RAM so the result of the mov
> >>>>>>>>>>> instruction cannot be known a priori. The halting program
> >>>>>>>>>>> concerns computing devices and a computing device which
> >>>>>>>>>>> cannot do I/O is next to useless, much like your decider
> >>>>>>>>>>> (until you actually prove otherwise which I have a feeling
> >>>>>>>>>>> is never going to happen as you appear to be stuck in a
> >>>>>>>>>>> loop).
> >>>>>>>>>>>
> >>>>>>>>>>> /Flibble
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I continue to note that you repeatedly refuse to address my
> >>>>>>>>> point regarding how x86 mov instructions can read/write
> >>>>>>>>> from/to memory mapped I/O rather than RAM so the result of
> >>>>>>>>> the mov instruction cannot be known a priori. The halting
> >>>>>>>>> program concerns computing devices and a computing device
> >>>>>>>>> which cannot do I/O is next to useless, much like your
> >>>>>>>>> decider (until you actually prove otherwise which I have a
> >>>>>>>>> feeling is never going to happen as you appear to be stuck
> >>>>>>>>> in a loop).
> >>>>>>>>>
> >>>>>>>>> /Flibble
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> You are the only one that believes that your points have any
> >>>>>>>> relevance. That you believe that data movement instructions
> >>>>>>>> have anything to do with control flow proves that your points
> >>>>>>>> have no relevance.
> >>>>>>>
> >>>>>>> You literally have no clue about what you are talking about,
> >>>>>>> whatsoever. This explains everything.
> >>>>>>>
> >>>>>>> /Flibble
> >>>>>>>
> >>>>>>
> >>>>>> *Make sure that you read all of this especially the last line*
> >>>>>>
> >>>>>> halt (p, i)
> >>>>>> {
> >>>>>> if ( program p halts on input i )
> >>>>>> return true ; // p halts
> >>>>>> else
> >>>>>> return false ; // p doesn’t halt
> >>>>>> }
> >>>>>> Fig. 1. Pseudocode of the Halting Function
> >>>>>>
> >>>>>> Strachey’s Impossible Program Strachey proposed a program
> >>>>>> based on the result of an assumed halting function [2].
> >>>>>> The way Strachey’s construction and other similar constructions
> >>>>>> are used to show the impossibility of a decideable halting
> >>>>>> function is quite similar to Turing’s original disproof.
> >>>>>> But the relevant difference we want to emphasize is that
> >>>>>> they do not explicitly assume an infinite number of possible
> >>>>>> machines (programs) or input data, because they directly use
> >>>>>> reductio ad absurdum to prove that both, Strachey’s
> >>>>>> construction and the universal halting function cannot exist.
> >>>>>>
> >>>>>> strachey ( p )
> >>>>>> {
> >>>>>> if ( halt (p, p) == true )
> >>>>>> L1 : goto L1 ; // loop forever
> >>>>>> else
> >>>>>> return;
> >>>>>> }
> >>>>>>
> >>>>>> Fig. 2. Strachey’s Impossible Program
> >>>>>>
> >>>>>> The impossibility of Strachey’s construction given in Figure 2
> >>>>>> becomes obvious if one tries to apply the halting function as
> >>>>>> follows:
> >>>>>>
> >>>>>> halt(strachey, strachey)
> >>>>>>
> >>>>>> Since in this case strachey() itself calls halt(strachey,
> >>>>>> strachey), it is required that the direct call of halt() and
> >>>>>> the nested call provide the same result. However, this leads
> >>>>>> to a contradiction, whatever result halt() returns. Within this
> >>>>>> disproof there seems to be no indication why not it could be
> >>>>>> even applied to finite-state systems having a concrete upper
> >>>>>> bound of state space.
> >>>>>>
> >>>>>> https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.206.1468&rep=rep1&type=pdf
> >>>>>>
> >>>>>
> >>>>> Except your decider can only handle trivial uninteresting cases:
> >>>>> if you
> >>>>
> >>>> Ask other people here if being able to correctly decide the
> >>>> strachey case is trivial or uninteresting. Ben might be the best
> >>>> one to ask about this.
> >>>>
> >>>> Here is his original 1965 letter.
> >>>> https://academic.oup.com/comjnl/article/7/4/313/354243
> >>>
> >>> All Strachey's letter shows is that a decider cannot be part of
> >>> that which is being decided.
> >>>
> >>> /Flibble
> >>>
> >>
> >>
> >> // Simplified Linz Ĥ (Linz:1990:319)
> >> void P(u32 x)
> >> {
> >> u32 Input_Halts = H(x, x);
> >> if (Input_Halts)
> >> HERE: goto HERE;
> >> }
> >>
> >> int main()
> >> {
> >> u32 Input_Halts = H((u32)P, (u32)P);
> >> Output("Input_Halts = ", Input_Halts);
> >> }
> >>
> >> What it shows is that the halting problem proof can be enormously
> >> simplified to the impossibility of the H(P,P) in main() returning a
> >> correct halt status value to main().
> >>
> >> *Here are Strachey's (verbatim) own words*
> >> Suppose T[R] is a Boolean function taking a routine
> >> (or program) R with no formal or free variables as its
> >> argument and that for all R, T[R] — True if R terminates
> >> if run and that T[R] = False if R does not terminate.
> >> Consider the routine P defined as follows
> >>
> >> rec routine P
> >> §L:if T[P] go to L
> >> Return §
> >>
> >> If T[P] = True the routine P will loop, and it will
> >> only terminate if T[P] = False. In each case T[P] has
> >> exactly the wrong value, and this contradiction shows
> >> that the function T cannot exist.
> >>
> >> Strachey is the creator of CPL ancestor to BCPL then B then C
> >> His code above is written in his CPL programming language.
> >
> > I repeat: all Strachey's letter shows is that a decider cannot be
> > part of that which is being decided.
> >
> > /Flibble
> >
>
> Although this <is> one way of putting it, all of the halting problem
> proofs require that the decider is a part of what is being decided.
> When we disallow that all of these proofs lose their entire basis and
> fail to prove anything.

Click here to read the complete article

On 7/10/2021 10:12 AM, André G. Isaak wrote:
> On 2021-07-10 08:25, olcott wrote:
>> On 7/10/2021 12:24 AM, André G. Isaak wrote:
>>> On 2021-07-09 22:45, olcott wrote:
>>>> On 7/9/2021 11:28 PM, André G. Isaak wrote:
>>>
>>>>> But by virtue of the way P is written, one of the nested
>>>>> simulations in P(P) is *always* aborted. Ergo the computation
>>>>> itself always halts.
>>>>>
>>>>
>>>> When one of the function calls of infinite recursion is aborted the
>>>> infinite recursion also stops running but this does not count as
>>>> halting because the only reason that any of it ever stopped running
>>>> is that one of the links of the infinite recursion chain was aborted.
>>>>
>>>> It is the same thing with infinitely nested simulation.
>>>
>>> Except that the topmost P, which is the one we are interested in,
>>> *isn't* a simulation. It is the thing doing the simulating and it
>>> isn't part of your chain of 'infinitely nested simulations'.
>>>
>>
>> Every H in the nested simulations of P(P) only acts as a pure
>> simulator on its input until after it makes its halt status decision.
>
> I am not talking about H(P, P). I am talking about P(P). Here, the
> outermost P (and the H in the outermost P) is *not* being simulated.
>
>> This means that every H Every H in the nested simulations of P(P) can
>> always screen out its own entire address range when examining the
>> execution trace of its input.
>>
>> _P()
>> [00000b1a](01)  55              push ebp
>> [00000b1b](02)  8bec            mov ebp,esp
>> [00000b1d](01)  51              push ecx
>> [00000b1e](03)  8b4508          mov eax,[ebp+08]
>> [00000b21](01)  50              push eax       // 2nd Param
>> [00000b22](03)  8b4d08          mov ecx,[ebp+08]
>> [00000b25](01)  51              push ecx       // 1st Param
>> [00000b26](05)  e81ffeffff      call 0000094a  // call H
>>
>> Begin Local Halt Decider Simulation at Machine Address:b1a
>> [00000b1a][002116e7][002116eb] 55         push ebp
>> [00000b1b][002116e7][002116eb] 8bec       mov ebp,esp
>> [00000b1d][002116e3][002016b7] 51         push ecx
>> [00000b1e][002116e3][002016b7] 8b4508     mov eax,[ebp+08]
>> [00000b21][002116df][00000b1a] 50         push eax      // push P
>> [00000b22][002116df][00000b1a] 8b4d08     mov ecx,[ebp+08]
>> [00000b25][002116db][00000b1a] 51         push ecx      // push P
>> [00000b26][002116d7][00000b2b] e81ffeffff call 0000094a // call H
>> [00000b1a][0025c10f][0025c113] 55         push ebp
>> [00000b1b][0025c10f][0025c113] 8bec       mov ebp,esp
>> [00000b1d][0025c10b][0024c0df] 51         push ecx
>> [00000b1e][0025c10b][0024c0df] 8b4508     mov eax,[ebp+08]
>> [00000b21][0025c107][00000b1a] 50         push eax      // push P
>> [00000b22][0025c107][00000b1a] 8b4d08     mov ecx,[ebp+08]
>> [00000b25][0025c103][00000b1a] 51         push ecx      // push P
>> [00000b26][0025c0ff][00000b2b] e81ffeffff call 0000094a // call H
>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>
>> This means the the above execution trace of P(P) determines that P(P)
>> never halts. P is stuck in infinitely nested simulation calling H(P,P)
>> which simulates P(P) which calls H(P,P)...
>>
>>> As I pointed out in an earlier post, given some simulator which has
>>> the ability to stop simulating its inputs under certain
>>> circumstances, there are only three logical possibilities:
>>>
>>> (1) The simulated computation continues until it reaches a final state.
>>>
>>> (2) The simulator decides to stop the simulation at some point.
>>>
>>> (3) The simulated computation is allowed to continue forever and is
>>> not aborted.
>>>
>>> In both cases (1) and (2) the SIMULATOR halts. The fact that the
>>> input never reaches its end in (2) isn't relevant to this fact
>>> regardless of whether the input is or is not a halting computation.
>>>
>>
>> As Richard aptly put it a computation that has had its simulation
>> aborted does not count as a computation that halts. Its computation
>> has been suspended. That the simulating halt decider halts has no
>> bearing on whether or not its input is a halting computation.
>
> But when P(P) is run independently, the outermost P *is* the simulator,
> and it *does* halt. The fact that its input has been suspended does not
> change this fact.

No P ever halts while every H remains a pure simulator thus meeting the
conventional criteria of UTM equivalence for never halting.

>
> And H(P, P) needs to answer the question "does the computation P(P) WHEN
> RUN AS AN INDEPENDENT COMPUTATION OUTSIDE OF H halt. It does. H(P, P)
> isn't being asked what happens to the input which P(P) is simulating.
>
> André
>

Until we remove the [liar paradox] pathological self-reference(Olcott
2004) error from the halting problem counter-example decisions these
counter examples remain incorrect.

Every problem / input instance of every decision problem that cannot be
decided cannot be decided because it is an incorrect (usually
self-contradictory) question.

Because the liar paradox is self-contradictory it is not a truth-bearer
and thus it has no truth value at all.

When we ask what Boolean value can a halt decider return to an input
that changes its behavior to contradict this value we cannot answer this
question because it is an incorrect type mismatch error question.

The answer is restricted to {true, false} thus excluding the correct
answer of neither making the question itself incorrect.

--
Copyright 2021 Pete Olcott

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

On 7/10/2021 10:25 AM, Mr Flibble wrote:
> On Sat, 10 Jul 2021 10:21:26 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 7/10/2021 10:15 AM, Mr Flibble wrote:
>>> On Sat, 10 Jul 2021 10:00:51 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 7/10/2021 9:30 AM, Mr Flibble wrote:
>>>>> On Sat, 10 Jul 2021 08:54:23 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 7/10/2021 6:40 AM, Mr Flibble wrote:
>>>>>>> On Fri, 9 Jul 2021 16:13:48 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> On 7/9/2021 4:08 PM, Mr Flibble wrote:
>>>>>>>>> On Fri, 9 Jul 2021 14:24:33 -0500
>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 7/9/2021 2:16 PM, Mr Flibble wrote:
>>>>>>>>>>> On Fri, 9 Jul 2021 12:47:12 -0500
>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 7/9/2021 12:06 PM, Mr Flibble wrote:
>>>>>>>>>>>>> On Fri, 9 Jul 2021 08:59:51 -0500
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>> [Halt Deciding Axiom] When the pure simulation of the
>>>>>>>>>>>>>> machine description ⟨P⟩ of a machine P on its input I
>>>>>>>>>>>>>> never halts we know that P(I) never halts.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No we cannot. In order to remove the pathological
>>>>>>>>>>>>>> feedback loop such that P does the opposite of whatever
>>>>>>>>>>>>>> H decides H simply acts as a pure simulator of P thus
>>>>>>>>>>>>>> having no effect what-so-ever on the behavior of P until
>>>>>>>>>>>>>> after its halt status decision has been made.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Except your decider can only handle trivial uninteresting
>>>>>>>>>>>>> cases: if you wish to make progress on this then prove
>>>>>>>>>>>>> your decider works with a non-trivial case which includes
>>>>>>>>>>>>> branching logic predicated on arbitrary program input that
>>>>>>>>>>>>> is unknown a priori to the simulation starting; but before
>>>>>>>>>>>>> you even do that prove your decider works with a
>>>>>>>>>>>>> non-trivial case with branching logic predicated on
>>>>>>>>>>>>> arbitrary program input that *is* known a priori.
>>>>>>>>>>>>
>>>>>>>>>>>> You continue to prove to everyone that actually knows these
>>>>>>>>>>>> things that you are an ignoramus on this subject.
>>>>>>>>>>>>
>>>>>>>>>>>> That H correctly decides that all of the standard
>>>>>>>>>>>> counter-examples templates never halt eliminates the entire
>>>>>>>>>>>> basis of all of the conventional halting problem
>>>>>>>>>>>> undecidability proofs.
>>>>>>>>>>>>> I also note that you repeatedly refuse to address my point
>>>>>>>>>>>>> regarding how x86 mov instructions can read/write from/to
>>>>>>>>>>>>> memory mapped I/O rather than RAM so the result of the mov
>>>>>>>>>>>>> instruction cannot be known a priori. The halting program
>>>>>>>>>>>>> concerns computing devices and a computing device which
>>>>>>>>>>>>> cannot do I/O is next to useless, much like your decider
>>>>>>>>>>>>> (until you actually prove otherwise which I have a feeling
>>>>>>>>>>>>> is never going to happen as you appear to be stuck in a
>>>>>>>>>>>>> loop).
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I continue to note that you repeatedly refuse to address my
>>>>>>>>>>> point regarding how x86 mov instructions can read/write
>>>>>>>>>>> from/to memory mapped I/O rather than RAM so the result of
>>>>>>>>>>> the mov instruction cannot be known a priori. The halting
>>>>>>>>>>> program concerns computing devices and a computing device
>>>>>>>>>>> which cannot do I/O is next to useless, much like your
>>>>>>>>>>> decider (until you actually prove otherwise which I have a
>>>>>>>>>>> feeling is never going to happen as you appear to be stuck
>>>>>>>>>>> in a loop).
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> You are the only one that believes that your points have any
>>>>>>>>>> relevance. That you believe that data movement instructions
>>>>>>>>>> have anything to do with control flow proves that your points
>>>>>>>>>> have no relevance.
>>>>>>>>>
>>>>>>>>> You literally have no clue about what you are talking about,
>>>>>>>>> whatsoever. This explains everything.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>
>>>>>>>> *Make sure that you read all of this especially the last line*
>>>>>>>>
>>>>>>>> halt (p, i)
>>>>>>>> {
>>>>>>>> if ( program p halts on input i )
>>>>>>>> return true ; // p halts
>>>>>>>> else
>>>>>>>> return false ; // p doesn’t halt
>>>>>>>> }
>>>>>>>> Fig. 1. Pseudocode of the Halting Function
>>>>>>>>
>>>>>>>> Strachey’s Impossible Program Strachey proposed a program
>>>>>>>> based on the result of an assumed halting function [2].
>>>>>>>> The way Strachey’s construction and other similar constructions
>>>>>>>> are used to show the impossibility of a decideable halting
>>>>>>>> function is quite similar to Turing’s original disproof.
>>>>>>>> But the relevant difference we want to emphasize is that
>>>>>>>> they do not explicitly assume an infinite number of possible
>>>>>>>> machines (programs) or input data, because they directly use
>>>>>>>> reductio ad absurdum to prove that both, Strachey’s
>>>>>>>> construction and the universal halting function cannot exist.
>>>>>>>>
>>>>>>>> strachey ( p )
>>>>>>>> {
>>>>>>>> if ( halt (p, p) == true )
>>>>>>>> L1 : goto L1 ; // loop forever
>>>>>>>> else
>>>>>>>> return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> Fig. 2. Strachey’s Impossible Program
>>>>>>>>
>>>>>>>> The impossibility of Strachey’s construction given in Figure 2
>>>>>>>> becomes obvious if one tries to apply the halting function as
>>>>>>>> follows:
>>>>>>>>
>>>>>>>> halt(strachey, strachey)
>>>>>>>>
>>>>>>>> Since in this case strachey() itself calls halt(strachey,
>>>>>>>> strachey), it is required that the direct call of halt() and
>>>>>>>> the nested call provide the same result. However, this leads
>>>>>>>> to a contradiction, whatever result halt() returns. Within this
>>>>>>>> disproof there seems to be no indication why not it could be
>>>>>>>> even applied to finite-state systems having a concrete upper
>>>>>>>> bound of state space.
>>>>>>>>
>>>>>>>> https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.206.1468&rep=rep1&type=pdf
>>>>>>>>
>>>>>>>
>>>>>>> Except your decider can only handle trivial uninteresting cases:
>>>>>>> if you
>>>>>>
>>>>>> Ask other people here if being able to correctly decide the
>>>>>> strachey case is trivial or uninteresting. Ben might be the best
>>>>>> one to ask about this.
>>>>>>
>>>>>> Here is his original 1965 letter.
>>>>>> https://academic.oup.com/comjnl/article/7/4/313/354243
>>>>>
>>>>> All Strachey's letter shows is that a decider cannot be part of
>>>>> that which is being decided.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>>
>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>> void P(u32 x)
>>>> {
>>>> u32 Input_Halts = H(x, x);
>>>> if (Input_Halts)
>>>> HERE: goto HERE;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> u32 Input_Halts = H((u32)P, (u32)P);
>>>> Output("Input_Halts = ", Input_Halts);
>>>> }
>>>>
>>>> What it shows is that the halting problem proof can be enormously
>>>> simplified to the impossibility of the H(P,P) in main() returning a
>>>> correct halt status value to main().
>>>>
>>>> *Here are Strachey's (verbatim) own words*
>>>> Suppose T[R] is a Boolean function taking a routine
>>>> (or program) R with no formal or free variables as its
>>>> argument and that for all R, T[R] — True if R terminates
>>>> if run and that T[R] = False if R does not terminate.
>>>> Consider the routine P defined as follows
>>>>
>>>> rec routine P
>>>> §L:if T[P] go to L
>>>> Return §
>>>>
>>>> If T[P] = True the routine P will loop, and it will
>>>> only terminate if T[P] = False. In each case T[P] has
>>>> exactly the wrong value, and this contradiction shows
>>>> that the function T cannot exist.
>>>>
>>>> Strachey is the creator of CPL ancestor to BCPL then B then C
>>>> His code above is written in his CPL programming language.
>>>
>>> I repeat: all Strachey's letter shows is that a decider cannot be
>>> part of that which is being decided.
>>>
>>> /Flibble
>>>
>>
>> Although this <is> one way of putting it, all of the halting problem
>> proofs require that the decider is a part of what is being decided.
>> When we disallow that all of these proofs lose their entire basis and
>> fail to prove anything.
>
> I agree, if these proofs do require a decider to be part of that which
> is being decided then they are indeed invalid for the reason Strachey
> highlights in his letter.
>
> /Flibble
>

On 7/10/2021 10:48 AM, André G. Isaak wrote:
> On 2021-07-10 09:32, olcott wrote:
>> On 7/10/2021 10:12 AM, André G. Isaak wrote:
>>> On 2021-07-10 08:25, olcott wrote:
>>>> On 7/10/2021 12:24 AM, André G. Isaak wrote:
>
>>>>> As I pointed out in an earlier post, given some simulator which has
>>>>> the ability to stop simulating its inputs under certain
>>>>> circumstances, there are only three logical possibilities:
>>>>>
>>>>> (1) The simulated computation continues until it reaches a final
>>>>> state.
>>>>>
>>>>> (2) The simulator decides to stop the simulation at some point.
>>>>>
>>>>> (3) The simulated computation is allowed to continue forever and is
>>>>> not aborted.
>>>>>
>>>>> In both cases (1) and (2) the SIMULATOR halts. The fact that the
>>>>> input never reaches its end in (2) isn't relevant to this fact
>>>>> regardless of whether the input is or is not a halting computation.
>>>>>
>>>>
>>>> As Richard aptly put it a computation that has had its simulation
>>>> aborted does not count as a computation that halts. Its computation
>>>> has been suspended. That the simulating halt decider halts has no
>>>> bearing on whether or not its input is a halting computation.
>>>
>>> But when P(P) is run independently, the outermost P *is* the
>>> simulator, and it *does* halt. The fact that its input has been
>>> suspended does not change this fact.
>>
>> No P ever halts while every H remains a pure simulator thus meeting
>> the conventional criteria of UTM equivalence for never halting.
>
> But H *isn't* a pure simulator.
>

Until the behavior of its input proves that it will never halt every H
remains a pure simulator of this input. When its input does prove that
it will never halt H suspends the execution of this input, thus this
non-halting input never halts. When a computation stops running because
its execution has been suspended this never counts as halting.

> If you change the H inside P to a pure simulator, then you are no longer
> talking about the same P. You're talking about some new machine, call it
> P2. That P2(P2) doesn't halt has no bearing on the fact that P(P) halts.
>

Until the behavior of its input proves that it will never halt every H
remains a pure simulator of this input. This single fact by itself
proves that the behavior of H has no effect what-so-ever on its halt
status decision.

> You can't determine the halting status of one computation by looking at
> some other computation.
>
> And what the hell does any of the above have to do with the C language,
> software engineering, or the philosophy of AI? These groups are entirely
> irrelevant.
>
> André
>

--
Copyright 2021 Pete Olcott

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

On 7/10/2021 11:34 AM, Mr Flibble wrote:
> On Sat, 10 Jul 2021 11:08:35 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 7/10/2021 10:25 AM, Mr Flibble wrote:
>>> On Sat, 10 Jul 2021 10:21:26 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 7/10/2021 10:15 AM, Mr Flibble wrote:
>>>>> On Sat, 10 Jul 2021 10:00:51 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 7/10/2021 9:30 AM, Mr Flibble wrote:
>>>>>>> On Sat, 10 Jul 2021 08:54:23 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> On 7/10/2021 6:40 AM, Mr Flibble wrote:
>>>>>>>>> On Fri, 9 Jul 2021 16:13:48 -0500
>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 7/9/2021 4:08 PM, Mr Flibble wrote:
>>>>>>>>>>> On Fri, 9 Jul 2021 14:24:33 -0500
>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 7/9/2021 2:16 PM, Mr Flibble wrote:
>>>>>>>>>>>>> On Fri, 9 Jul 2021 12:47:12 -0500
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 7/9/2021 12:06 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>> On Fri, 9 Jul 2021 08:59:51 -0500
>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>> [Halt Deciding Axiom] When the pure simulation of the
>>>>>>>>>>>>>>>> machine description ⟨P⟩ of a machine P on its input I
>>>>>>>>>>>>>>>> never halts we know that P(I) never halts.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No we cannot. In order to remove the pathological
>>>>>>>>>>>>>>>> feedback loop such that P does the opposite of whatever
>>>>>>>>>>>>>>>> H decides H simply acts as a pure simulator of P thus
>>>>>>>>>>>>>>>> having no effect what-so-ever on the behavior of P
>>>>>>>>>>>>>>>> until after its halt status decision has been made.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Except your decider can only handle trivial
>>>>>>>>>>>>>>> uninteresting cases: if you wish to make progress on
>>>>>>>>>>>>>>> this then prove your decider works with a non-trivial
>>>>>>>>>>>>>>> case which includes branching logic predicated on
>>>>>>>>>>>>>>> arbitrary program input that is unknown a priori to the
>>>>>>>>>>>>>>> simulation starting; but before you even do that prove
>>>>>>>>>>>>>>> your decider works with a non-trivial case with
>>>>>>>>>>>>>>> branching logic predicated on arbitrary program input
>>>>>>>>>>>>>>> that *is* known a priori.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You continue to prove to everyone that actually knows
>>>>>>>>>>>>>> these things that you are an ignoramus on this subject.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That H correctly decides that all of the standard
>>>>>>>>>>>>>> counter-examples templates never halt eliminates the
>>>>>>>>>>>>>> entire basis of all of the conventional halting problem
>>>>>>>>>>>>>> undecidability proofs.
>>>>>>>>>>>>>>> I also note that you repeatedly refuse to address my
>>>>>>>>>>>>>>> point regarding how x86 mov instructions can read/write
>>>>>>>>>>>>>>> from/to memory mapped I/O rather than RAM so the result
>>>>>>>>>>>>>>> of the mov instruction cannot be known a priori. The
>>>>>>>>>>>>>>> halting program concerns computing devices and a
>>>>>>>>>>>>>>> computing device which cannot do I/O is next to
>>>>>>>>>>>>>>> useless, much like your decider (until you actually
>>>>>>>>>>>>>>> prove otherwise which I have a feeling is never going
>>>>>>>>>>>>>>> to happen as you appear to be stuck in a loop).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I continue to note that you repeatedly refuse to address
>>>>>>>>>>>>> my point regarding how x86 mov instructions can read/write
>>>>>>>>>>>>> from/to memory mapped I/O rather than RAM so the result of
>>>>>>>>>>>>> the mov instruction cannot be known a priori. The halting
>>>>>>>>>>>>> program concerns computing devices and a computing device
>>>>>>>>>>>>> which cannot do I/O is next to useless, much like your
>>>>>>>>>>>>> decider (until you actually prove otherwise which I have a
>>>>>>>>>>>>> feeling is never going to happen as you appear to be stuck
>>>>>>>>>>>>> in a loop).
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> You are the only one that believes that your points have
>>>>>>>>>>>> any relevance. That you believe that data movement
>>>>>>>>>>>> instructions have anything to do with control flow proves
>>>>>>>>>>>> that your points have no relevance.
>>>>>>>>>>>
>>>>>>>>>>> You literally have no clue about what you are talking about,
>>>>>>>>>>> whatsoever. This explains everything.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *Make sure that you read all of this especially the last
>>>>>>>>>> line*
>>>>>>>>>>
>>>>>>>>>> halt (p, i)
>>>>>>>>>> {
>>>>>>>>>> if ( program p halts on input i )
>>>>>>>>>> return true ; // p halts
>>>>>>>>>> else
>>>>>>>>>> return false ; // p doesn’t halt
>>>>>>>>>> }
>>>>>>>>>> Fig. 1. Pseudocode of the Halting Function
>>>>>>>>>>
>>>>>>>>>> Strachey’s Impossible Program Strachey proposed a program
>>>>>>>>>> based on the result of an assumed halting function [2].
>>>>>>>>>> The way Strachey’s construction and other similar
>>>>>>>>>> constructions are used to show the impossibility of a
>>>>>>>>>> decideable halting function is quite similar to Turing’s
>>>>>>>>>> original disproof. But the relevant difference we want to
>>>>>>>>>> emphasize is that they do not explicitly assume an infinite
>>>>>>>>>> number of possible machines (programs) or input data,
>>>>>>>>>> because they directly use reductio ad absurdum to prove that
>>>>>>>>>> both, Strachey’s construction and the universal halting
>>>>>>>>>> function cannot exist.
>>>>>>>>>>
>>>>>>>>>> strachey ( p )
>>>>>>>>>> {
>>>>>>>>>> if ( halt (p, p) == true )
>>>>>>>>>> L1 : goto L1 ; // loop forever
>>>>>>>>>> else
>>>>>>>>>> return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> Fig. 2. Strachey’s Impossible Program
>>>>>>>>>>
>>>>>>>>>> The impossibility of Strachey’s construction given in Figure
>>>>>>>>>> 2 becomes obvious if one tries to apply the halting function
>>>>>>>>>> as follows:
>>>>>>>>>>
>>>>>>>>>> halt(strachey, strachey)
>>>>>>>>>>
>>>>>>>>>> Since in this case strachey() itself calls halt(strachey,
>>>>>>>>>> strachey), it is required that the direct call of halt() and
>>>>>>>>>> the nested call provide the same result. However, this leads
>>>>>>>>>> to a contradiction, whatever result halt() returns. Within
>>>>>>>>>> this disproof there seems to be no indication why not it
>>>>>>>>>> could be even applied to finite-state systems having a
>>>>>>>>>> concrete upper bound of state space.
>>>>>>>>>>
>>>>>>>>>> https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.206.1468&rep=rep1&type=pdf
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Except your decider can only handle trivial uninteresting
>>>>>>>>> cases: if you
>>>>>>>>
>>>>>>>> Ask other people here if being able to correctly decide the
>>>>>>>> strachey case is trivial or uninteresting. Ben might be the
>>>>>>>> best one to ask about this.
>>>>>>>>
>>>>>>>> Here is his original 1965 letter.
>>>>>>>> https://academic.oup.com/comjnl/article/7/4/313/354243
>>>>>>>
>>>>>>> All Strachey's letter shows is that a decider cannot be part of
>>>>>>> that which is being decided.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>>
>>>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>>>> void P(u32 x)
>>>>>> {
>>>>>> u32 Input_Halts = H(x, x);
>>>>>> if (Input_Halts)
>>>>>> HERE: goto HERE;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> u32 Input_Halts = H((u32)P, (u32)P);
>>>>>> Output("Input_Halts = ", Input_Halts);
>>>>>> }
>>>>>>
>>>>>> What it shows is that the halting problem proof can be enormously
>>>>>> simplified to the impossibility of the H(P,P) in main()
>>>>>> returning a correct halt status value to main().
>>>>>>
>>>>>> *Here are Strachey's (verbatim) own words*
>>>>>> Suppose T[R] is a Boolean function taking a routine
>>>>>> (or program) R with no formal or free variables as its
>>>>>> argument and that for all R, T[R] — True if R terminates
>>>>>> if run and that T[R] = False if R does not terminate.
>>>>>> Consider the routine P defined as follows
>>>>>>
>>>>>> rec routine P
>>>>>> §L:if T[P] go to L
>>>>>> Return §
>>>>>>
>>>>>> If T[P] = True the routine P will loop, and it will
>>>>>> only terminate if T[P] = False. In each case T[P] has
>>>>>> exactly the wrong value, and this contradiction shows
>>>>>> that the function T cannot exist.
>>>>>>
>>>>>> Strachey is the creator of CPL ancestor to BCPL then B then C
>>>>>> His code above is written in his CPL programming language.
>>>>>
>>>>> I repeat: all Strachey's letter shows is that a decider cannot be
>>>>> part of that which is being decided.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> Although this <is> one way of putting it, all of the halting
>>>> problem proofs require that the decider is a part of what is being
>>>> decided. When we disallow that all of these proofs lose their
>>>> entire basis and fail to prove anything.
>>>
>>> I agree, if these proofs do require a decider to be part of that
>>> which is being decided then they are indeed invalid for the reason
>>> Strachey highlights in his letter.
>>>
>>> /Flibble
>>>
>>
>> I have been saying that they are invalid since 2004, now you are
>> agreeing with me on this.
>>
>> comp.theory Peter Olcott Sep 5, 2004, 11:21:57 AM
>> The Liar Paradox can be shown to be nothing more than
>> a incorrectly formed statement because of its pathological
>> self-reference. The Halting Problem can only exist because
>> of this same sort of pathological self-reference.
>> https://groups.google.com/g/comp.theory/c/RO9Z9eCabeE/m/Ka8-xS2rdEEJ
>>
>> Everyone else believes that they are valid and prove that the halting
>> problem is undecidable.
>
> They are not valid as [Strachey 1965] falsifies them (if what you say
> is correct) HOWEVER given that it doesn't follow that the halting
> problem itself is not undecidable just that those particular proofs are
> invalid.
>
> /Flibble
>

Mr Flibble <flibble@reddwarf.jmc> writes:
[196 lines deleted]

*Please* stop cross-posting this stuff to comp.lang.c, or to any group
other than comp.theory. I know it's olcott who insists on adding
irrelevant newsgroups, but I don't see his posts. Please edit the
Newsgroups: header line before posting a followup.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 7/10/2021 5:19 PM, Keith Thompson wrote:
> Mr Flibble <flibble@reddwarf.jmc> writes:
> [196 lines deleted]
>
> *Please* stop cross-posting this stuff to comp.lang.c, or to any group
> other than comp.theory. I know it's olcott who insists on adding
> irrelevant newsgroups, but I don't see his posts. Please edit the
> Newsgroups: header line before posting a followup.
>

I need Kaz or Mike to respond to Flibble's post.

My best reviewer: Kaz only responded to my posts because I posted to
comp.lang.c and several other language groups.

My cancer is at stage 3, I want to get my work approved before I die.

--
Copyright 2021 Pete Olcott

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

In article <877dhx7qww.fsf@nosuchdomain.example.com>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>Mr Flibble <flibble@reddwarf.jmc> writes:
>[196 lines deleted]
>
>*Please* stop cross-posting this stuff to comp.lang.c, or to any group
>other than comp.theory. I know it's olcott who insists on adding
>irrelevant newsgroups, but I don't see his posts. Please edit the
>Newsgroups: header line before posting a followup.

Like you did?

--
The only thing Trump's made great again is Saturday Night Live.

On 7/10/2021 7:29 PM, Kenny McCormack wrote:
> In article <877dhx7qww.fsf@nosuchdomain.example.com>,
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Mr Flibble <flibble@reddwarf.jmc> writes:
>> [196 lines deleted]
>>
>> *Please* stop cross-posting this stuff to comp.lang.c, or to any group
>> other than comp.theory. I know it's olcott who insists on adding
>> irrelevant newsgroups, but I don't see his posts. Please edit the
>> Newsgroups: header line before posting a followup.
>
> Like you did?
>

Flibble is only reviewing my work because I cross-posted and it turns
out that he is a great reviewer. Kaz Kylheku only reviewed my work
because I cross-posted and he is my best reviewer so far.

--
Copyright 2021 Pete Olcott

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

On 7/10/2021 10:33 PM, Keith Thompson wrote:
> olcott <NoOne@NoWhere.com> writes:
> [...]
>>> In article <877dhx7qww.fsf@nosuchdomain.example.com>,
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>> Mr Flibble <flibble@reddwarf.jmc> writes:
>>>> [196 lines deleted]
>>>>
>>>> *Please* stop cross-posting this stuff to comp.lang.c, or to any group
>>>> other than comp.theory. I know it's olcott who insists on adding
>>>> irrelevant newsgroups, but I don't see his posts. Please edit the
>>>> Newsgroups: header line before posting a followup.
> [...]
>>
>> Flibble is only reviewing my work because I cross-posted and it turns
>> out that he is a great reviewer. Kaz Kylheku only reviewed my work
>> because I cross-posted and he is my best reviewer so far.
>
> olcott, I wasn't talking to you. I'm aware that you'll continue to
> annoy people by cross-posting to inappropriate newsgroups. I've dealt
> with that by killfiling you in comp.lang.c. I'm asking those who reply
> to you, including Flibble and Kaz, to restrict their followups to
> comp.theory, whether you do or not. You're a lost cause. They might
> not be.
>
> I'm aware that some newsreaders might make it difficult to edit the
> Newsgroups: header line.
>

Wouldn't it be worth the slight annoyance of a little cross-posting if
the cross-posting made the difference between actually validating that
the halting problem proofs really have been correctly refuted?

--
Copyright 2021 Pete Olcott

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