On 7/16/2021 10:12 AM, Andy Walker wrote:
> On 16/07/2021 14:39, Mr Flibble wrote:
>> On Fri, 16 Jul 2021 14:34:54 +0100
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>> Mr Flibble <flibble@reddwarf.jmc> quotes:
>>>>     Suppose T[R] is a Boolean function taking a routine
>>>>     (or program) R with no formal or free variables as its
>>>>     argument [...].
>>>> Consider the routine P defined as follows

>>>>         rec routine P
>>>>             §L :if T[P] goto L
>>>>         Return §
> [...]
>>>> T is indeed unable to decide P but for the wrong reason: T[P] is
>>>> recursive
>
>     I suppose one should not point out that "P", as defined, has
> "T" as a free variable, so is not a valid parameter to "T"?  But that's
> a quibble, as "P" could be re-written to have the code for "H" included.
>
>>> T[P] is not recursive.  Maybe you don't understand what the CPL means?

http://www.ancientgeek.org.uk/CPL/CPL_Working_Papers.pdf
10.3.1 seems to indicate that rec routine P means that P is recursive.

>> Of course it is recursive, such is obvious even to the casual reader
>> who is unfamiliar with the CPL language (a clue: read the paragraph
>> before the definition of P again).
>
>     "T[P]" is recursive only if "T" calls "P".  That is a pretty
> daft thing to do.  "Does this program ever halt?" "Dunno, let's find

Here is my best estimate of the CPL written in C:

void P()
{ if (T((u32)P)
HERE: goto HERE;
}

> out by running it."  If that doesn't seem stupid, imagine replacing
> "halt" by "kill the patient" or "blow up this nuclear power station".
> So a well-written "T" will not call its parameter.  This makes the
> whole argument as currently being debated moot;  if you don't call a
> routine, then pretty much all you can do with it is assign it or pass
> it as a parameter/operand, neither of which gets us any nearer to
> deciding whether it halts [or kills people].
>
>     But in this form, it also has nothing to do with the Halting
> Problem, which would not be about some "T" that /calls/ "P" but about
> one that /inspects/ "P".  So the only sensible interpretation of what
> Strachey wrote is that the parameter to "T" is the /source/ of some
> program or routine "P".  In most languages, that source would be of
> "string" or perhaps "file" type or similar.  "P" would then be the
> string quoted above [preferably with also the string corresponding
> to the source of "T"].  Once this simple interpretation is made, the
> fundamental Strachey/Minsky/Sipser/Linz argument works perfectly well
> with no question of recursion [infinite, "pathological" or otherwise]
> unless "T" chooses it.
>
>     That is why I have several times suggested, though with little
> success, that participants in this debate should be very clear about
> whether they are talking about "source" or "executable".  Simply
> calling things "H", "P", "T", "H_hat", ... does not convey this
> [necessary] information, and leads to Olcottian confusions.  Perhaps
> some contributors prefer to obscure the argument.
>

In my case when P is passed to P it is the machine address of the
machine language of P that is directly executed by an x86 emulator. This
eliminates all of the extraneous complexity of switching back and forth
between the machine and its description. The x86 description of P <is> P.

--
Copyright 2021 Pete Olcott

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

On 7/16/2021 11:11 AM, wij wrote:
> On Friday, 16 July 2021 at 23:52:53 UTC+8, olcott wrote:
>> On 7/16/2021 10:12 AM, Andy Walker wrote:
>>> On 16/07/2021 14:39, Mr Flibble wrote:
>>>> On Fri, 16 Jul 2021 14:34:54 +0100
>>>> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>>>>> Mr Flibble <fli...@reddwarf.jmc> quotes:
>>>>>> Suppose T[R] is a Boolean function taking a routine
>>>>>> (or program) R with no formal or free variables as its
>>>>>> argument [...].
>>>>>> Consider the routine P defined as follows
>>
>>>>>> rec routine P
>>>>>> §L :if T[P] goto L
>>>>>> Return §
>>> [...]
>>>>>> T is indeed unable to decide P but for the wrong reason: T[P] is
>>>>>> recursive
>>>
>>> I suppose one should not point out that "P", as defined, has
>>> "T" as a free variable, so is not a valid parameter to "T"? But that's
>>> a quibble, as "P" could be re-written to have the code for "H" included.
>>>
>>>>> T[P] is not recursive. Maybe you don't understand what the CPL means?
>> http://www.ancientgeek.org.uk/CPL/CPL_Working_Papers.pdf
>> 10.3.1 seems to indicate that rec routine P means that P is recursive.
>>>> Of course it is recursive, such is obvious even to the casual reader
>>>> who is unfamiliar with the CPL language (a clue: read the paragraph
>>>> before the definition of P again).
>>>
>>> "T[P]" is recursive only if "T" calls "P". That is a pretty
>>> daft thing to do. "Does this program ever halt?" "Dunno, let's find
>> Here is my best estimate of the CPL written in C:
>>
>> void P()
>> {
>> if (T((u32)P)
>> HERE: goto HERE;
>> }
>>
>>> out by running it." If that doesn't seem stupid, imagine replacing
>>> "halt" by "kill the patient" or "blow up this nuclear power station".
>>> So a well-written "T" will not call its parameter. This makes the
>>> whole argument as currently being debated moot; if you don't call a
>>> routine, then pretty much all you can do with it is assign it or pass
>>> it as a parameter/operand, neither of which gets us any nearer to
>>> deciding whether it halts [or kills people].
>>>
>>> But in this form, it also has nothing to do with the Halting
>>> Problem, which would not be about some "T" that /calls/ "P" but about
>>> one that /inspects/ "P". So the only sensible interpretation of what
>>> Strachey wrote is that the parameter to "T" is the /source/ of some
>>> program or routine "P". In most languages, that source would be of
>>> "string" or perhaps "file" type or similar. "P" would then be the
>>> string quoted above [preferably with also the string corresponding
>>> to the source of "T"]. Once this simple interpretation is made, the
>>> fundamental Strachey/Minsky/Sipser/Linz argument works perfectly well
>>> with no question of recursion [infinite, "pathological" or otherwise]
>>> unless "T" chooses it.
>>>
>>> That is why I have several times suggested, though with little
>>> success, that participants in this debate should be very clear about
>>> whether they are talking about "source" or "executable". Simply
>>> calling things "H", "P", "T", "H_hat", ... does not convey this
>>> [necessary] information, and leads to Olcottian confusions. Perhaps
>>> some contributors prefer to obscure the argument.
>>>
>> In my case when P is passed to P it is the machine address of the
>> machine language of P that is directly executed by an x86 emulator. This
>> eliminates all of the extraneous complexity of switching back and forth
>> between the machine and its description. The x86 description of P <is> P.
>> --
>> Copyright 2021 Pete Olcott
>>
>> "Great spirits have always encountered violent opposition from mediocre
>> minds." Einstein
>
> IMO, DOS + x86 assembly is already a TM simulator.
> x86 emulator is redundant. Besides, the input of the x86 emulator
> seems have to be COFF, this would made x86 emulator not a valid
> proof machine (input and execution codes are different).
>

A halt decider must have absolute control over its slave process.
H steps through P(P) one instruction at a time and immediately aborts
its simulation of P(P) as soon as the next instruction of P indicates
that P is stuck in infinitely nested simulation.

--
Copyright 2021 Pete Olcott

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