On 11/20/21 12:45 PM, olcott wrote:
> On 11/20/2021 12:57 AM, André G. Isaak wrote:
>> On 2021-11-19 17:16, olcott wrote:
>>> On 11/19/2021 5:33 PM, André G. Isaak wrote:
>>>> On 2021-11-19 15:15, olcott wrote:
>>>>> On 11/19/2021 3:05 PM, André G. Isaak wrote:
>>>>>> On 2021-11-19 13:13, olcott wrote:
>>>>>>> On 11/19/2021 2:03 PM, André G. Isaak wrote:
>>>>>>>> On 2021-11-19 12:26, olcott wrote:
>>>>>>>>> On 11/19/2021 12:31 PM, André G. Isaak wrote:
>>>>>>>>>> On 2021-11-19 11:06, olcott wrote:
>>>>>>>>>>> On 11/19/2021 11:46 AM, André G. Isaak wrote:
>>>>>>>>>>>> On 2021-11-19 10:32, olcott wrote:
>>>>>>>>>>
>>>>>>>>>>>>> The input to (H,P) never halts P(P) halts.
>>>>>>>>>>>>> Here are the divergent execution sequences at the C level:
>>>>>>>>>>>>>
>>>>>>>>>>>>> int main(){ H(P,P); }
>>>>>>>>>>>>> (1) main()
>>>>>>>>>>>>> (2) calls H(P,P) that simulates the input to H(P,P)
>>>>>>>>>>>>> (3) that calls H(P,P) which aborts its simulation of P(P)
>>>>>>>>>>>>> and returns to
>>>>>>>>>>>>> (4) main().
>>>>>>>>>>>>>
>>>>>>>>>>>>> int main(){ P(P); }
>>>>>>>>>>>>> (a) main() calls P(P) that
>>>>>>>>>>>>> (b) calls H(P,P) that simulates the input to H(P,P)
>>>>>>>>>>>>> (c) that calls H(P,P) which aborts its simulation of P(P)
>>>>>>>>>>>>> and returns to
>>>>>>>>>>>>> (d) P(P) that returns to main()
>>>>>>>>>>>>>
>>>>>>>>>>>>> (1) diverges from (a) causing (4) to diverge from (d)
>>>>>>>>>>>>
>>>>>>>>>>>> And a halt decider is concerned only with the SECOND case,
>>>>>>>>>>>> not the first.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The halt decider is concerned with the execution trace of a
>>>>>>>>>>> sequence of instructions other than the actual execution
>>>>>>>>>>> trace that is specified by actually executing or simulating
>>>>>>>>>>> its actual input?
>>>>>>>>>>
>>>>>>>>>> Your question makes no sense.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It is proven that the execution trace of P(P) and the execution
>>>>>>>>> trace of the input to H(P,P) are not the same and that this
>>>>>>>>> difference results in different behavior.
>>>>>>>>
>>>>>>>> And the halting problem, BY DEFINITION, is concerned only with
>>>>>>>> the former. The latter is not of interest to anyone.
>>>>>>>>
>>>>>>>
>>>>>>> It may seem that way until you realize that any other case would
>>>>>>> not be reporting on the actual behavior of the actual sequence of
>>>>>>> instructions specified by the actual execution trace of the
>>>>>>> actual simulation or execution of its actual input.
>>>>>>
>>>>>> The definition is what it is. A halt reporter reports on the
>>>>>> behaviour of the computation described by its input when that
>>>>>> computation is run as an independent computation; not when it is
>>>>>> wrapped inside your H.
>>>>>>
>>>>>> Just because you don't like the definition doesn't mean you can
>>>>>> change it.
>>>>>
>>>>> given the description of a Turing machine M and an input w, does M,
>>>>> when started in the initial configuration q0 w, perform a
>>>>> computation that eventually halts? (Linz:1990:317)
>>>>>
>>>>> In other words: Does UTM(M, w) halt?
>>>>
>>>> That definition makes no mention of UTMs, and he carefully
>>>> distinguishes between the description of M (which he elsewhere
>>>> notates as w_M).
>>>>
>>>> But yes, UTM(w_M, w) will halt if and only if M(w) halts.
>>>>
>>>
>>> Because the behavior of the UTM simulation of the machine description
>>> of TM X on input Y is defined to precisely correspond to the direct
>>> execution of TM X on input Y we can also always rely on the following:
>>>
>>> If UTM U is adapted to become a halt decider H for a subset of inputs
>>> Z such that it aborts the simulation of its input only when the
>>> behavior of the pure simulation of this input conclusively proves
>>> that this input would never reach its final state, then H can abort
>>> the simulation of every element of Z and correctly report that its
>>> input does not halt.
>>
>> The fact that UTM(M, w) and M(w) have the same halting status has no
>> bearing on the definition of a halt decider and provides no
>> justification for the above.
>>
>> The input to UTM(M, w) doesn't have a halting status anymore than the
>> input to H does. Only actual computations have a halting status. So
>> you can ask about whether UTM(M, w) halts, or about whether the
>> computation described by its input halts, but not about whether the
>> input halts.
>
>
>
>> H(P, P) may or may not reach a final state. P(P) may or may not reach
>> a final state. It is meaningless, though, to talk about the input to
>> H(P, P) reaching a final state.
>>
>> André
>>
>>
>
> Not when the [PSR set] if the basis for this claim:
>
> Computation that halts
> a computation is said to halt whenever it enters a final state.
> (Linz:1990:234)
>
> PSR set: Combinations of H/P having pathological self-reference
> For every possible H of H(P,P) invoked from main() where P(P) calls this
> same H(P,P) and H simulates or executes its input and aborts or does not
> abort its input P never reaches its last instruction.
>

WRONG. LIE.

There are two distinct subsets of your PSR set.

There are those Hs that do not abort their simulation/execution of their
input when it is their P(P), and for THOSE Hs, which we can lable Hn,
(and there related P as Pn) it is true that Pn(Pn) will be non-halting,
but it is also true that Hn(Pn,Pn) will never return a value.

There is a second group of Hs, that DO abort their simulation/execution
of their input when it is their P(P). We can lable these Hs as Ha (and
there related P as Pa). While it is true that the processing inside
Ha(Pa,Pa) will never reach a halting state, this failure does NOT show
non-halting, as an aborted simulation fails to meet the defintion. When
we DIRECTLY EXECUTE Pa(Pa), ie directly run the input to that Ha, we see
that Pa(Pa) will HALT.

You statement is just a bald face LIE, because you LIE at what you are
looking at.

> PSR subset: Because we know that the input to H(P,P) never halts for the
> whole PSR set and a subset of these H/P combinations aborts the
> execution or simulation of its input then we know that for this entire
> subset the input to H(P,P) never halts and H(P,P) halts.
>

WRONG. LIE.

> When int main(void) { P(P); } is invoked on H/P elements of the above
> PSR subset, then we have a cases where the input to H(P,P) never halts
> and P(P) halts.
>

WRONG. LIE. The DEFINITION of the input to H(P,P) IS the representation
P(P). What doesn't reach a halting state is the aborted

> The above cases conclusively prove that when the input to H(P,P) never
> halts and the same P(P) does halt that this does not form any
> contradiction.

Right, Not a contradict, just a proof that you LIE.

If P(P) halts then the input to H(P,P) also halts, BY DEFINITION.

What doesn't reach a halting state is the aborted simulation of the
input done by H which is not the computation specified by the phrase
'input halting' if you are working in the domain of Computation Theory
and the Halting problen=m.

In other words, you are just lying through your teeth.

>
> Decidable_PSR subset: The subset of the PSR subset where H returns 0 on
> the basis that H correctly detects that P specifies infinite recursion
> defines the decidable domain of function H.

EMPTY SET, as H NEVER returns 0 CORRECTLY, as EVERY TIME H(P,P) return
0, then the input to H, the compuation P(P) will halt.

PERIOD.

FAIL.

YOU LIE.

>
> H is a function that correctly maps every element of its domain to {0,1}
> on the basis of whether or not these elements reach their final state
> and halt. On this basis H is a halt decider.
>
>
>

Nope, FLAT OUT LIE.

Are your REALLY claiming this? That means you have just claimed the
UNIVERSAL halt decider. Can it solve the Twin Primes problem?