On 7/28/2021 6:36 PM, André G. Isaak wrote:
> On 2021-07-28 14:06, olcott wrote:
>> On 7/28/2021 1:40 PM, André G. Isaak wrote:
>>> On 2021-07-28 10:38, olcott wrote:
>>>> On 7/28/2021 10:31 AM, André G. Isaak wrote:
>>>>> On 2021-07-28 08:09, olcott wrote:
>>>>>> On 7/27/2021 10:39 PM, André G. Isaak wrote:
>>>>>
>>>>>>> So does P(P) halt or not?
>>>>>>>
>>>>>>
>>>>>> Even though the first P in the invocation sequence reaches its
>>>>>> final state the fact that it only reaches its final state because
>>>>>> the second P in the invocation sequence was aborted proves that
>>>>>> H(P,P)==0 is correct.
>>>>>
>>>>> If a car only crashes because its brakes failed, that does not
>>>>> imply that it didn't crash.
>>>>>
>>>>> If a program returns the wrong result only because it has a bug,
>>>>> that does not imply that it didn't return the right answer.
>>>>>
>>>>> If a program only halts because the second P was aborted, that does
>>>>> not imply that it didn't halt.
>>>>>
>>>>
>>>> If an infinitely recursive sequence of function calls is aborted on
>>>> the second call instead of the first call that does not mean that it
>>>> was not an infinitely recursive sequence.
>>>
>>> But the definition of halting makes no mention of infinitely
>>> recursive sequences or aborted function calls. It only requires that
>>> P(P) reach a final state in a finite amount of time. P(P) meets this
>>> definition.
>>>
>>
>> If we base the decision on whether or not P halts entirely on the fact
>> that it reaches its final state
>
> That's the DEFINITION of halting, so of course that's the only thing we
> should base the decision of whether P halts on.
>

This is equally the definition of not halting:
Every input to a simulating halt decider that only stops running when
its simulation is aborted unequivocally specifies a computation that
never halts.

>> then we have the same situation as "This sentence is not true." It is
>> indeed not true and the definition of a true sentence is whether or
>> not its assertion is satisfied.
>
> I fail to see any parallels between P and the liar.
>
>> When we explicitly take into account the self-contradictory nature of
>> these two cases things are not as cut-and-dried.
>
> There's nothing self-contradictory about it.
>
>> "This sentence is not true." is indeed not true yet when we apply this
>> to the satisfaction of the whole sentence and not just its assertion
>
> That is gibberish.
>
>> then we get a contradiction. If it is true that it is not true then
>> that makes is not true.
>>
>> It is an easily verifiable fact that the input to H(P,P) cannot
>> possibly reach its final state while H remains a pure simulator.
>> Because H
>
> But the definition of halting makes no reference to what H does at all,
> nor to pure simulators. whether P(P) halts is based solely on the
> behaviour of P(P).
>

The definition of UTM does make reference to computational equivalence
forcing this statement to be necessarily true:

Every input to a simulating halt decider that only stops running when
its simulation is aborted unequivocally specifies a computation that
never halts.

>> remains a pure simulator until after it makes its halt status decision
>> then its decision that its input never halts is necessarily correct.
>>
>> That the first P in the infinitely recursive sequence reaches its
>> final state after H has made its correct halt status decision is just
>> like saying the liar paradox is true on the basis that its assertion
>> is satisfied.
>
> No. That the first P reaches its final state means that P(P) halts. The
> definition of halting doesn't care how or why it reaches this state.
> Only that it does.

So then we must conclude the the self contradictory input causes the
logic of the system to be inconsistent because it proves that P halts
and it proves that P never halts.

>>>>>> Because this is too difficult to understand and accept I have
>>>>>> temporarily changed the subject to refuting Rice's theorem. The
>>>>>> fact that the first P reaches its final state and the second P is
>>>>>> aborted can   be used as the criterion measure to consistently
>>>>>> reject all and only self-contradictory inputs. This does refute
>>>>>> Rices theorem.
>>>>>>
>>>>>>> You have on the one hand acknowledged that it does, while at the
>>>>>>> same time claimed that it doesn't halt in a 'pure simulator'. So
>>>>>>> if your 'global simulator' is not a pure simulator, what kind of
>>>>>>> simulator is it?
>>>>>
>>>>> You didn't answer the above. In the past you've claimed (falsely)
>>>>> that in a pure simulator, P(P) doesn't halt.
>>>>>
>>>>
>>>> While H remains a pure simulator of its input H(P,P) its input never
>>>> halts thus proving that its input never halts.
>>>
>>> But the definition of halting makes no mention of what happens inside
>>> H, regardless of whether it remains a 'pure simulator'. It only
>>> requires that the actual computation P(P) reach a final state in a
>>> finite amount of time. P(P) meets this definition.
>>>
>>>>> Now you appear to be using your 'global simulator' to recognise
>>>>> that P(P) does halt so that you can compare this with the results
>>>>> of H(P, P).
>>>>
>>>> It is still true that H(P,P) did correctly decide that its input
>>>> never halts. Because this is difficult to understand I am
>>>> temporarily changing the subject to Rice's theorem.
>>>
>>> No, it is not. The definition of halting is clearly defined, and P(P)
>>> clearly meets the definition of halting. Rice's theorem has no
>>> bearing on the fact that P(P) is halting computation.
>>>
>>
>> In this exact same way we would have to say that the liar paradox is
>> true because its assertion that it is not true is fully satisfied.
>
> The LP's "assertion that it is not true" is *not* satisfied, fully or
> otherwise.

The Liar Paradox: "This sentence is not true."
is indeed provably not true on the basis that it leads to a
contradiction and on the basis that it specifies and infinite cycle.

Only my own unique work finally resolves this:

Apparently in all of the years prior to my original (2016) paper no one
ever separated the analysis of propositions into their atomic units of
semantic compositionality:
(a) Assertion (Boolean) // What the expression of language claims to
be True
(b) Satisfied (Boolean) // Whether or not the expression of language
is True

https://www.researchgate.net/publication/323866366_The_Notion_of_Truth_in_Natural_and_Formal_Languages

> P(P), on the other hand, fully meets the definition of halting.
>
>> Whenever the assertion of a declarative sentence is satisfied we know
>> that this declarative sentence is true unless this declarative
>> sentence is self-contradictory.
>>
>> Whenever H decides that its input never halts its input never reaches
>> a final state. When its input is self-contradictory then another
>> different
>
> The input to H is simply *data*. Halting applies to *computations*.
>

Not exactly: UTM(P,I) ≡ P(I)

>> instance of the program that is not an input to H may halt.
>>
>>>>> But if P(P) doesn't halt in a 'pure simulator' then what kind of
>>>>
>>>> I did not say that P(P) does not halt in a pure simulator, you must
>>>> pay careful attention to every single word that I say. When you skip
>>>> a single word that reverses the meaning of what I say.
>>>>
>>>> The input to H(P,P) never halts while H remains in pure simulator mode.
>>>
>>> So what's the difference between a 'pure simulator' and H running in
>>> 'pure simulator mode'? One would have assumed that the latter meant
>>> that H was acting as a pure simulator.
>>>
>>
>> H is evaluating the halt status of its input on the basis of what the
>> behavior of this input would be if H never aborts the simulation of
>> this input.
>
> Which is the wrong criterion for evaluating this. The correct criterion
> is simply whether P(P) reaches a final state.
>
> <snippage>
>
>> The bottom line is that self-contradiction must be treated
>> differently, the conventional rules do not apply to self-contradiction.
>
> Where does the definition of halting entail some class which must be
> treated differently? All computations either reach a final state in a
> finite amount of time or they do not. There is no third option.
>

On 7/28/21 4:21 PM, olcott wrote:
> On 7/28/2021 5:22 PM, Richard Damon wrote:
>> On 7/28/21 3:08 PM, olcott wrote:
>>> On 7/26/2021 6:48 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> While the input to H(P,P) is simulated in pure simulation mode it
>>>>> cannot possibly ever reach a final state thus conclusively proving
>>>>> that this input never halts.
>>>>
>>>> Who cares?  H(P,P) == 0 and P(P) halts so H is not a halt decider.  You
>>>> once claimed something "interesting" i.e. that you had
>>>>
>>>>     "encoded all of the ... Linz Turing machine H that correctly
>>>> decides
>>>>     halting for its fully encoded input pair: (Ĥ, Ĥ)"
>>>>
>>>> and you insisted that
>>>>
>>>>     "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
>>>>     specs does not exist. I now have a fully encoded pair of Turing
>>>>     Machines H / Ĥ proving them wrong."
>>>>
>>>> Does that "Linz Turing machine H" accept or reject the "fully encoded
>>>> input pair (H^, H^)", and what is the halting status if H^ when
>>>> given H^
>>>> (encoded)?  If, as now, H rejects (H^, H^) but H^ halts when given H^
>>>> then there was never anything interesting about what you were claiming,
>>>> but it was at least about Turing machines and the proof you have
>>>> fixated
>>>> on.
>>>>
>>>> But you also said your TMs H and H^ are "exactly and precisely as in
>>>> Linz", so really either
>>>>
>>>>     (1) H rejects (H^, H^) and H^ does not halt on input H^, or
>>>>     (2) H accepts (H^, H^) and H^ halts on input H^
>>>>
>>>> should be the case.  So, come clean.  Which was the case back then:
>>>>
>>>>     (1) H rejects (H^, H^) and H^ does not halt in input H^, or
>>>>     (2) H accepts (H^, H^) and H^ halts on input H^, or
>>>>     (3) H rejects (H^, H^) and H^ halts on input H^.
>>>>
>>>> Without the comfort blanket of your huge pile of junk x86 code, I
>>>> suspect you won't dare say.
>>>>
>>>
>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
>>> if M applied to wM halts, and
>>>
>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>>> if M applied to wM does not halt
>>>
>>> When we apply Ĥ to its own TM description ⟨Ĥ⟩
>>>
>>> While the simulating halt decider at Ĥ.qx remains in pure simulator mode
>>> it specifies a never ending cycle from     qx to q0.
>>
>> Right, and such an H fails to answer to H(H^,H^) so it has failed before
>> we even can check if it got the right answer.
>>
>
> Such an Ĥ uses this as its basis to know that its input unequivocally
> specifies infinite execution that must be aborted.
>
> Every input to a simulating halt decider that only stops running when
> its simulation is aborted unequivocally specifies a computation that
> never halts.
>

As you have been told that is the wrong definition.

The RIGHT definition is that if the machine represented by that input
reaches a halting state in a finite nunber of steps.

You could also say if this input was given to a compatible UTM, then if
that simulation would halt in a finite number of step the computation is
Halting.

You H is NOT the equivalent of a UTM, as it will abort its simulation
under certain conditions, and it has been shown that it does abort some
finite machine before they reach their final halting state.

WRONG DEFINITION, WRONG ANSWWER. INVALID and UNSOUND logic.

On 7/28/21 6:54 PM, olcott wrote:
> On 7/28/2021 7:58 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/28/2021 6:22 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 7/26/2021 6:48 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> While the input to H(P,P) is simulated in pure simulation mode it
>>>>>>> cannot possibly ever reach a final state thus conclusively proving
>>>>>>> that this input never halts.
>>>>>> Who cares?  H(P,P) == 0 and P(P) halts so H is not a halt
>>>>>> decider.  You
>>>>>> once claimed something "interesting" i.e. that you had
>>>>>>      "encoded all of the ... Linz Turing machine H that correctly
>>>>>> decides
>>>>>>      halting for its fully encoded input pair: (Ĥ, Ĥ)"
>>>>>> and you insisted that
>>>>>>      "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the
>>>>>> Linz
>>>>>>      specs does not exist. I now have a fully encoded pair of Turing
>>>>>>      Machines H / Ĥ proving them wrong."
>>>>>> Does that "Linz Turing machine H" accept or reject the "fully encoded
>>>>>> input pair (H^, H^)", and what is the halting status if H^ when
>>>>>> given H^
>>>>>> (encoded)?  If, as now, H rejects (H^, H^) but H^ halts when given H^
>>>>>> then there was never anything interesting about what you were
>>>>>> claiming,
>>>>>> but it was at least about Turing machines and the proof you have
>>>>>> fixated
>>>>>> on.
>>>>>> But you also said your TMs H and H^ are "exactly and precisely as in
>>>>>> Linz", so really either
>>>>>>      (1) H rejects (H^, H^) and H^ does not halt on input H^, or
>>>>>>      (2) H accepts (H^, H^) and H^ halts on input H^
>>>>>> should be the case.  So, come clean.  Which was the case back then:
>>>>>>      (1) H rejects (H^, H^) and H^ does not halt in input H^, or
>>>>>>      (2) H accepts (H^, H^) and H^ halts on input H^, or
>>>>>>      (3) H rejects (H^, H^) and H^ halts on input H^.
>>>>>> Without the comfort blanket of your huge pile of junk x86 code, I
>>>>>> suspect you won't dare say.
>>>>>
>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
>>>>> if M applied to wM halts, and
>>>>>
>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>>>>> if M applied to wM does not halt
>>>>>
>>>>> When we apply Ĥ to its own TM description ⟨Ĥ⟩
>>>> If you didn't understand the question, I might be able to explain it
>>>> some other way.  If you are just avoiding answering it, then just
>>>> say so
>>>> and I'll stop asking.
>>>
>>> I totally ignored the convoluted mess of your question...
>>
>> Would you like to know what I was asking, or do you just want to keep
>> posting stuff for your entertainment?  It's simpler for me if you are
>> not interested in knowing what I was asking, and I think it helps other
>> readers form an opinion as well.
>>
>
> It was just another one of your endless dishonest dodges as can be seen
> above This quote proves you are clueless: "H rejects (H^, H^)"
>
> The freaking question at the end of the proof is what happens when Ĥ is
> applied to its own Turing machine description.
>
> The freaking question at the end of the proof is what happens when Ĥ is
> applied to its own Turing machine description.
>
> The freaking question at the end of the proof is what happens when Ĥ is
> applied to its own Turing machine description.
>
> Every simulation that would never stop unless its simulating halt
> decider stops it at some point specifies infinite execution.
> This remains true for: Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩)
>
> Ĥ( ⟨Ĥ⟩ ) only stops because its simulating halt decider stops it at some
> point.
>

WRONG.

H^(H^) Halts because the copy of the algorithm of H when given the input
H^(H^) decided that H^(H^) was non-halting by simulating that COPY and
aborting its simulation of THAT COPY.

The actual H^ machine was NEVER aborted, because it was never being
simulated, just run.

On 7/28/21 8:51 PM, olcott wrote:
> On 7/28/2021 6:36 PM, André G. Isaak wrote:
>> On 2021-07-28 14:06, olcott wrote:
>>> On 7/28/2021 1:40 PM, André G. Isaak wrote:
>>>> On 2021-07-28 10:38, olcott wrote:
>>>>> On 7/28/2021 10:31 AM, André G. Isaak wrote:
>>>>>> On 2021-07-28 08:09, olcott wrote:
>>>>>>> On 7/27/2021 10:39 PM, André G. Isaak wrote:
>>>>>>
>>>>>>>> So does P(P) halt or not?
>>>>>>>>
>>>>>>>
>>>>>>> Even though the first P in the invocation sequence reaches its
>>>>>>> final state the fact that it only reaches its final state because
>>>>>>> the second P in the invocation sequence was aborted proves that
>>>>>>> H(P,P)==0 is correct.
>>>>>>
>>>>>> If a car only crashes because its brakes failed, that does not
>>>>>> imply that it didn't crash.
>>>>>>
>>>>>> If a program returns the wrong result only because it has a bug,
>>>>>> that does not imply that it didn't return the right answer.
>>>>>>
>>>>>> If a program only halts because the second P was aborted, that
>>>>>> does not imply that it didn't halt.
>>>>>>
>>>>>
>>>>> If an infinitely recursive sequence of function calls is aborted on
>>>>> the second call instead of the first call that does not mean that
>>>>> it was not an infinitely recursive sequence.
>>>>
>>>> But the definition of halting makes no mention of infinitely
>>>> recursive sequences or aborted function calls. It only requires that
>>>> P(P) reach a final state in a finite amount of time. P(P) meets this
>>>> definition.
>>>>
>>>
>>> If we base the decision on whether or not P halts entirely on the
>>> fact that it reaches its final state
>>
>> That's the DEFINITION of halting, so of course that's the only thing
>> we should base the decision of whether P halts on.
>>
>
> This is equally the definition of not halting:
> Every input to a simulating halt decider that only stops running when
> its simulation is aborted unequivocally specifies a computation that
> never halts.

WRONG. If the simulating Halt decider aborts its simulator too early,
then the input might never reach its actual halting state,

The test is to replace the decider with a TRUE UTM, and see if that
reaches its Halting State.

For H^(H^), given that H(H^,H^) returns non-halting, the answer is YES,
so it is a Halting Computation.

>
>>> then we have the same situation as "This sentence is not true." It is
>>> indeed not true and the definition of a true sentence is whether or
>>> not its assertion is satisfied.
>>
>> I fail to see any parallels between P and the liar.
>>
>>> When we explicitly take into account the self-contradictory nature of
>>> these two cases things are not as cut-and-dried.
>>
>> There's nothing self-contradictory about it.
>>
>>> "This sentence is not true." is indeed not true yet when we apply
>>> this to the satisfaction of the whole sentence and not just its
>>> assertion
>>
>> That is gibberish.
>>
>>> then we get a contradiction. If it is true that it is not true then
>>> that makes is not true.
>>>
>>> It is an easily verifiable fact that the input to H(P,P) cannot
>>> possibly reach its final state while H remains a pure simulator.
>>> Because H
>>
>> But the definition of halting makes no reference to what H does at
>> all, nor to pure simulators. whether P(P) halts is based solely on the
>> behaviour of P(P).
>>
>
> The definition of UTM does make reference to computational equivalence
> forcing this statement to be necessarily true:
>
> Every input to a simulating halt decider that only stops running when
> its simulation is aborted unequivocally specifies a computation that
> never halts.

No. Not the way you view it. See above.

>
>>> remains a pure simulator until after it makes its halt status
>>> decision then its decision that its input never halts is necessarily
>>> correct.
>>>
>>> That the first P in the infinitely recursive sequence reaches its
>>> final state after H has made its correct halt status decision is just
>>> like saying the liar paradox is true on the basis that its assertion
>>> is satisfied.
>>
>> No. That the first P reaches its final state means that P(P) halts.
>> The definition of halting doesn't care how or why it reaches this
>> state. Only that it does.
>
> So then we must conclude the the self contradictory input causes the
> logic of the system to be inconsistent because it proves that P halts
> and it proves that P never halts.

Yes, you get it. YOUR logic is inconsistent.

Given a specific H, the results of H^ are firmly determined and consistent.

By the PROPER definition, H(H^,H^) says non-halting but H^(H^) is
halting, as can be verified by running UTM(H^,H^) if you want to be
doing a simulation. There is NO inconsistency.

Only by adding YOUR definitions do we hit an inconsistency, showing the
source of this problem.

Adding a 'rule' like "Since no H simulates its H^ to its halting point,
that shows that H^ is non-halting" is what gives us the inconsistency,
because the statement is WRONG.

>

On 7/28/2021 10:36 PM, André G. Isaak wrote:
> On 2021-07-28 21:25, olcott wrote:
>> On 7/28/2021 6:25 PM, André G. Isaak wrote:
>>> On 2021-07-28 13:07, olcott wrote:
>>>
>>>>> So what exactly happens for a *genuine* non-halting computation?
>>>>> Your H returns 0 for non-halting and your Simulate runs forever to
>>>>> confirm that this is correct? Remember that a decider, by
>>>>> definition, must *halt*.
>>>>>
>>>>> André
>>>>>
>>>>
>>>> When H is fully elaborated to become a full decider its divides all
>>>> inputs into halting / (not-halting or PSR Error), this still refutes
>>>> Rice.
>>>
>>> First off, that wasn't an answer to my question.
>>>
>>> Secondly, (not halting or PSR error) isn't a legitimate semantic
>>> property so it has nothing to do with Rice.
>>>
>>> Halting vs. Non-Halting would be a legitimate semantic property.
>>>
>>> Halting vs. Non-Halting + all the cases H get wrong isn't.
>>>
>>> André
>>>
>>>
>>
>> This is an improvement over what anyone else has ever done:

>> Every input to a simulating halt decider that only stops running when
>> its simulation is aborted unequivocally specifies a computation that
>> never halts.
>
> That's not the definition of halting. How does using the wrong
> definition to get the wrong answer qualify as 'an improvement over what
> anyone else has done'?
>

If you really think it through you may realize that because UTM(P,I) ≡
P(I) it must be correct.

>> The P of int main(){ P(P); } is one of these inputs therefore H
>> correctly decides that it never halts.
>
> P(P) in main isn't an input to anything. It's a computation. And it halts.
>
> André
>
>

--
Copyright 2021 Pete Olcott

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

On 2021-07-28 21:51, olcott wrote:
> On 7/28/2021 6:36 PM, André G. Isaak wrote:
>> On 2021-07-28 14:06, olcott wrote:
>>> On 7/28/2021 1:40 PM, André G. Isaak wrote:
>>>> On 2021-07-28 10:38, olcott wrote:
>>>>> On 7/28/2021 10:31 AM, André G. Isaak wrote:
>>>>>> On 2021-07-28 08:09, olcott wrote:
>>>>>>> On 7/27/2021 10:39 PM, André G. Isaak wrote:
>>>>>>
>>>>>>>> So does P(P) halt or not?
>>>>>>>>
>>>>>>>
>>>>>>> Even though the first P in the invocation sequence reaches its
>>>>>>> final state the fact that it only reaches its final state because
>>>>>>> the second P in the invocation sequence was aborted proves that
>>>>>>> H(P,P)==0 is correct.
>>>>>>
>>>>>> If a car only crashes because its brakes failed, that does not
>>>>>> imply that it didn't crash.
>>>>>>
>>>>>> If a program returns the wrong result only because it has a bug,
>>>>>> that does not imply that it didn't return the right answer.
>>>>>>
>>>>>> If a program only halts because the second P was aborted, that
>>>>>> does not imply that it didn't halt.
>>>>>>
>>>>>
>>>>> If an infinitely recursive sequence of function calls is aborted on
>>>>> the second call instead of the first call that does not mean that
>>>>> it was not an infinitely recursive sequence.
>>>>
>>>> But the definition of halting makes no mention of infinitely
>>>> recursive sequences or aborted function calls. It only requires that
>>>> P(P) reach a final state in a finite amount of time. P(P) meets this
>>>> definition.
>>>>
>>>
>>> If we base the decision on whether or not P halts entirely on the
>>> fact that it reaches its final state
>>
>> That's the DEFINITION of halting, so of course that's the only thing
>> we should base the decision of whether P halts on.
>>
>
> This is equally the definition of not halting:
> Every input to a simulating halt decider that only stops running when
> its simulation is aborted unequivocally specifies a computation that
> never halts.

No, it isn't a definition of halting. At best, it is something which you
have proposed as a *test* for halting, but it is a broken test since, at
least according to you, it sometimes gives an answer that does *not*
correspond to the *actual* definition of halting.

>>> then we have the same situation as "This sentence is not true." It is
>>> indeed not true and the definition of a true sentence is whether or
>>> not its assertion is satisfied.
>>
>> I fail to see any parallels between P and the liar.
>>
>>> When we explicitly take into account the self-contradictory nature of
>>> these two cases things are not as cut-and-dried.
>>
>> There's nothing self-contradictory about it.
>>
>>> "This sentence is not true." is indeed not true yet when we apply
>>> this to the satisfaction of the whole sentence and not just its
>>> assertion
>>
>> That is gibberish.
>>
>>> then we get a contradiction. If it is true that it is not true then
>>> that makes is not true.
>>>
>>> It is an easily verifiable fact that the input to H(P,P) cannot
>>> possibly reach its final state while H remains a pure simulator.
>>> Because H
>>
>> But the definition of halting makes no reference to what H does at
>> all, nor to pure simulators. whether P(P) halts is based solely on the
>> behaviour of P(P).
>>
>
> The definition of UTM does make reference to computational equivalence
> forcing this statement to be necessarily true:

Please show me a definition of UTM which makes reference to
computational equivalence.

> Every input to a simulating halt decider that only stops running when
> its simulation is aborted unequivocally specifies a computation that
> never halts.

A 'simulating halt decider' and UTM are different things.

>>> remains a pure simulator until after it makes its halt status
>>> decision then its decision that its input never halts is necessarily
>>> correct.
>>>
>>> That the first P in the infinitely recursive sequence reaches its
>>> final state after H has made its correct halt status decision is just
>>> like saying the liar paradox is true on the basis that its assertion
>>> is satisfied.
>>
>> No. That the first P reaches its final state means that P(P) halts.
>> The definition of halting doesn't care how or why it reaches this
>> state. Only that it does.
>
> So then we must conclude the the self contradictory input causes the
> logic of the system to be inconsistent because it proves that P halts
> and it proves that P never halts.

It shows the logic of the *decider* to be inconsistent. It doesn't show
anything inconsistent about the definition of halting, nor does it
provide to treat a computation which halts as anything other than a
computation which halts.

Whether P(P) halts is a question which is independent of any 'halt decider'.

H cannot decide P(P) correctly. Other partial deciders are able to
decide it correctly. But the definition of halting makes no reference to
whether any other TM can decide it correctly. It refers only to whether
P(P) reaches a final state in a finite number of steps. It does.
Therefore it halts.

>>>>>>> Because this is too difficult to understand and accept I have
>>>>>>> temporarily changed the subject to refuting Rice's theorem. The
>>>>>>> fact that the first P reaches its final state and the second P is
>>>>>>> aborted can   be used as the criterion measure to consistently
>>>>>>> reject all and only self-contradictory inputs. This does refute
>>>>>>> Rices theorem.
>>>>>>>
>>>>>>>> You have on the one hand acknowledged that it does, while at the
>>>>>>>> same time claimed that it doesn't halt in a 'pure simulator'. So
>>>>>>>> if your 'global simulator' is not a pure simulator, what kind of
>>>>>>>> simulator is it?
>>>>>>
>>>>>> You didn't answer the above. In the past you've claimed (falsely)
>>>>>> that in a pure simulator, P(P) doesn't halt.
>>>>>>
>>>>>
>>>>> While H remains a pure simulator of its input H(P,P) its input
>>>>> never halts thus proving that its input never halts.
>>>>
>>>> But the definition of halting makes no mention of what happens
>>>> inside H, regardless of whether it remains a 'pure simulator'. It
>>>> only requires that the actual computation P(P) reach a final state
>>>> in a finite amount of time. P(P) meets this definition.
>>>>
>>>>>> Now you appear to be using your 'global simulator' to recognise
>>>>>> that P(P) does halt so that you can compare this with the results
>>>>>> of H(P, P).
>>>>>
>>>>> It is still true that H(P,P) did correctly decide that its input
>>>>> never halts. Because this is difficult to understand I am
>>>>> temporarily changing the subject to Rice's theorem.
>>>>
>>>> No, it is not. The definition of halting is clearly defined, and
>>>> P(P) clearly meets the definition of halting. Rice's theorem has no
>>>> bearing on the fact that P(P) is halting computation.
>>>>
>>>
>>> In this exact same way we would have to say that the liar paradox is
>>> true because its assertion that it is not true is fully satisfied.
>>
>> The LP's "assertion that it is not true" is *not* satisfied, fully or
>> otherwise.
>
> The Liar Paradox: "This sentence is not true."
> is indeed provably not true on the basis that it leads to a
> contradiction and on the basis that it specifies and infinite cycle.
>
> Only my own unique work finally resolves this:
>
> Apparently in all of the years prior to my original (2016) paper no one
> ever separated the analysis of propositions into their atomic units of
> semantic compositionality:
> (a) Assertion  (Boolean) //  What the expression of language claims to
> be True
> (b) Satisfied   (Boolean) //  Whether or not the expression of language
> is True

On 7/28/2021 11:15 PM, André G. Isaak wrote:
> On 2021-07-28 21:51, olcott wrote:
>> On 7/28/2021 6:36 PM, André G. Isaak wrote:
>>> On 2021-07-28 14:06, olcott wrote:
>>>> On 7/28/2021 1:40 PM, André G. Isaak wrote:
>>>>> On 2021-07-28 10:38, olcott wrote:
>>>>>> On 7/28/2021 10:31 AM, André G. Isaak wrote:
>>>>>>> On 2021-07-28 08:09, olcott wrote:
>>>>>>>> On 7/27/2021 10:39 PM, André G. Isaak wrote:
>>>>>>>
>>>>>>>>> So does P(P) halt or not?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Even though the first P in the invocation sequence reaches its
>>>>>>>> final state the fact that it only reaches its final state
>>>>>>>> because the second P in the invocation sequence was aborted
>>>>>>>> proves that H(P,P)==0 is correct.
>>>>>>>
>>>>>>> If a car only crashes because its brakes failed, that does not
>>>>>>> imply that it didn't crash.
>>>>>>>
>>>>>>> If a program returns the wrong result only because it has a bug,
>>>>>>> that does not imply that it didn't return the right answer.
>>>>>>>
>>>>>>> If a program only halts because the second P was aborted, that
>>>>>>> does not imply that it didn't halt.
>>>>>>>
>>>>>>
>>>>>> If an infinitely recursive sequence of function calls is aborted
>>>>>> on the second call instead of the first call that does not mean
>>>>>> that it was not an infinitely recursive sequence.
>>>>>
>>>>> But the definition of halting makes no mention of infinitely
>>>>> recursive sequences or aborted function calls. It only requires
>>>>> that P(P) reach a final state in a finite amount of time. P(P)
>>>>> meets this definition.
>>>>>
>>>>
>>>> If we base the decision on whether or not P halts entirely on the
>>>> fact that it reaches its final state
>>>
>>> That's the DEFINITION of halting, so of course that's the only thing
>>> we should base the decision of whether P halts on.
>>>
>>
>> This is equally the definition of not halting:
>> Every input to a simulating halt decider that only stops running when
>> its simulation is aborted unequivocally specifies a computation that
>> never halts.
>
> No, it isn't a definition of halting. At best, it is something which you
> have proposed as a *test* for halting, but it is a broken test since, at
> least according to you, it sometimes gives an answer that does *not*
> correspond to the *actual* definition of halting.
>

It is computationally equivalent to not halting.

>
>>>> then we have the same situation as "This sentence is not true." It
>>>> is indeed not true and the definition of a true sentence is whether
>>>> or not its assertion is satisfied.
>>>
>>> I fail to see any parallels between P and the liar.
>>>
>>>> When we explicitly take into account the self-contradictory nature
>>>> of these two cases things are not as cut-and-dried.
>>>
>>> There's nothing self-contradictory about it.
>>>
>>>> "This sentence is not true." is indeed not true yet when we apply
>>>> this to the satisfaction of the whole sentence and not just its
>>>> assertion
>>>
>>> That is gibberish.
>>>
>>>> then we get a contradiction. If it is true that it is not true then
>>>> that makes is not true.
>>>>
>>>> It is an easily verifiable fact that the input to H(P,P) cannot
>>>> possibly reach its final state while H remains a pure simulator.
>>>> Because H
>>>
>>> But the definition of halting makes no reference to what H does at
>>> all, nor to pure simulators. whether P(P) halts is based solely on
>>> the behaviour of P(P).
>>>
>>
>> The definition of UTM does make reference to computational equivalence
>> forcing this statement to be necessarily true:
>
> Please show me a definition of UTM which makes reference to
> computational equivalence.
>

The simulation of the TM description of TM P on input I is stipulated to
be computationally equivalent to P(I). In an honest dialogue I would not
have to repeat this fifty times.

>> Every input to a simulating halt decider that only stops running when
>> its simulation is aborted unequivocally specifies a computation that
>> never halts.
>
> A 'simulating halt decider' and UTM are different things.
>

Not while the simulating halt decider is in pure simulator mode.

>>>> remains a pure simulator until after it makes its halt status
>>>> decision then its decision that its input never halts is necessarily
>>>> correct.
>>>>
>>>> That the first P in the infinitely recursive sequence reaches its
>>>> final state after H has made its correct halt status decision is
>>>> just like saying the liar paradox is true on the basis that its
>>>> assertion is satisfied.
>>>
>>> No. That the first P reaches its final state means that P(P) halts.
>>> The definition of halting doesn't care how or why it reaches this
>>> state. Only that it does.
>>
>> So then we must conclude the the self contradictory input causes the
>> logic of the system to be inconsistent because it proves that P halts
>> and it proves that P never halts.
>
> It shows the logic of the *decider* to be inconsistent. It doesn't show
> anything inconsistent about the definition of halting, nor does it
> provide to treat a computation which halts as anything other than a
> computation which halts.
>

Within the hypothesis that this is correct:
Within the hypothesis that this is correct:
Within the hypothesis that this is correct:
Within the hypothesis that this is correct:

Every input to a simulating halt decider that only stops running when
its simulation is aborted unequivocally specifies a computation that
never halts.

Then the fact that the first P of int main(){ P(P); } reaches its final
state wold seem to prove that we are getting the same contradiction as
the liar paradox.

This make perfect sense:
garbage in (self contradictory input)
garbage out (contradictory result).

> Whether P(P) halts is a question which is independent of any 'halt
> decider'.
>
> H cannot decide P(P) correctly. Other partial deciders are able to
> decide it correctly. But the definition of halting makes no reference to
> whether any other TM can decide it correctly. It refers only to whether
> P(P) reaches a final state in a finite number of steps. It does.
> Therefore it halts.
>
>>>>>>>> Because this is too difficult to understand and accept I have
>>>>>>>> temporarily changed the subject to refuting Rice's theorem. The
>>>>>>>> fact that the first P reaches its final state and the second P
>>>>>>>> is aborted can   be used as the criterion measure to
>>>>>>>> consistently reject all and only self-contradictory inputs. This
>>>>>>>> does refute Rices theorem.
>>>>>>>>
>>>>>>>>> You have on the one hand acknowledged that it does, while at
>>>>>>>>> the same time claimed that it doesn't halt in a 'pure
>>>>>>>>> simulator'. So if your 'global simulator' is not a pure
>>>>>>>>> simulator, what kind of simulator is it?
>>>>>>>
>>>>>>> You didn't answer the above. In the past you've claimed (falsely)
>>>>>>> that in a pure simulator, P(P) doesn't halt.
>>>>>>>
>>>>>>
>>>>>> While H remains a pure simulator of its input H(P,P) its input
>>>>>> never halts thus proving that its input never halts.
>>>>>
>>>>> But the definition of halting makes no mention of what happens
>>>>> inside H, regardless of whether it remains a 'pure simulator'. It
>>>>> only requires that the actual computation P(P) reach a final state
>>>>> in a finite amount of time. P(P) meets this definition.
>>>>>
>>>>>>> Now you appear to be using your 'global simulator' to recognise
>>>>>>> that P(P) does halt so that you can compare this with the results
>>>>>>> of H(P, P).
>>>>>>
>>>>>> It is still true that H(P,P) did correctly decide that its input
>>>>>> never halts. Because this is difficult to understand I am
>>>>>> temporarily changing the subject to Rice's theorem.
>>>>>
>>>>> No, it is not. The definition of halting is clearly defined, and
>>>>> P(P) clearly meets the definition of halting. Rice's theorem has no
>>>>> bearing on the fact that P(P) is halting computation.
>>>>>
>>>>
>>>> In this exact same way we would have to say that the liar paradox is
>>>> true because its assertion that it is not true is fully satisfied.
>>>
>>> The LP's "assertion that it is not true" is *not* satisfied, fully or
>>> otherwise.
>>
>> The Liar Paradox: "This sentence is not true."
>> is indeed provably not true on the basis that it leads to a
>> contradiction and on the basis that it specifies and infinite cycle.
>>
>> Only my own unique work finally resolves this:
>>
>> Apparently in all of the years prior to my original (2016) paper no
>> one ever separated the analysis of propositions into their atomic
>> units of semantic compositionality:
>> (a) Assertion  (Boolean) //  What the expression of language claims to
>> be True
>> (b) Satisfied   (Boolean) //  Whether or not the expression of
>> language is True
>
> You've raised this before. It's as meaningless now as it was when you
> first suggested it.
>

On 7/28/21 9:09 PM, olcott wrote:
> On 7/28/2021 10:36 PM, André G. Isaak wrote:
>> On 2021-07-28 21:25, olcott wrote:
>>> On 7/28/2021 6:25 PM, André G. Isaak wrote:
>>>> On 2021-07-28 13:07, olcott wrote:
>>>>
>>>>>> So what exactly happens for a *genuine* non-halting computation?
>>>>>> Your H returns 0 for non-halting and your Simulate runs forever to
>>>>>> confirm that this is correct? Remember that a decider, by
>>>>>> definition, must *halt*.
>>>>>>
>>>>>> André
>>>>>>
>>>>>
>>>>> When H is fully elaborated to become a full decider its divides all
>>>>> inputs into halting / (not-halting or PSR Error), this still
>>>>> refutes Rice.
>>>>
>>>> First off, that wasn't an answer to my question.
>>>>
>>>> Secondly, (not halting or PSR error) isn't a legitimate semantic
>>>> property so it has nothing to do with Rice.
>>>>
>>>> Halting vs. Non-Halting would be a legitimate semantic property.
>>>>
>>>> Halting vs. Non-Halting + all the cases H get wrong isn't.
>>>>
>>>> André
>>>>
>>>>
>>>
>>> This is an improvement over what anyone else has ever done:
>
>>> Every input to a simulating halt decider that only stops running when
>>> its simulation is aborted unequivocally specifies a computation that
>>> never halts.
>>
>> That's not the definition of halting. How does using the wrong
>> definition to get the wrong answer qualify as 'an improvement over
>> what anyone else has done'?
>>
>
> If you really think it through you may realize that because UTM(P,I) ≡
> P(I) it must be correct.

Right, but H is NOT a UTM.

>
>>> The P of int main(){ P(P); } is one of these inputs therefore H
>>> correctly decides that it never halts.
>>
>> P(P) in main isn't an input to anything. It's a computation. And it
>> halts.
>>
>> André
>>
>>
>
>

On 7/28/2021 11:50 PM, Richard Damon wrote:
> On 7/28/21 9:09 PM, olcott wrote:
>> On 7/28/2021 10:36 PM, André G. Isaak wrote:
>>> On 2021-07-28 21:25, olcott wrote:
>>>> On 7/28/2021 6:25 PM, André G. Isaak wrote:
>>>>> On 2021-07-28 13:07, olcott wrote:
>>>>>
>>>>>>> So what exactly happens for a *genuine* non-halting computation?
>>>>>>> Your H returns 0 for non-halting and your Simulate runs forever to
>>>>>>> confirm that this is correct? Remember that a decider, by
>>>>>>> definition, must *halt*.
>>>>>>>
>>>>>>> André
>>>>>>>
>>>>>>
>>>>>> When H is fully elaborated to become a full decider its divides all
>>>>>> inputs into halting / (not-halting or PSR Error), this still
>>>>>> refutes Rice.
>>>>>
>>>>> First off, that wasn't an answer to my question.
>>>>>
>>>>> Secondly, (not halting or PSR error) isn't a legitimate semantic
>>>>> property so it has nothing to do with Rice.
>>>>>
>>>>> Halting vs. Non-Halting would be a legitimate semantic property.
>>>>>
>>>>> Halting vs. Non-Halting + all the cases H get wrong isn't.
>>>>>
>>>>> André
>>>>>
>>>>>
>>>>
>>>> This is an improvement over what anyone else has ever done:
>>
>>>> Every input to a simulating halt decider that only stops running when
>>>> its simulation is aborted unequivocally specifies a computation that
>>>> never halts.
>>>
>>> That's not the definition of halting. How does using the wrong
>>> definition to get the wrong answer qualify as 'an improvement over
>>> what anyone else has done'?
>>>
>>
>> If you really think it through you may realize that because UTM(P,I) ≡
>> P(I) it must be correct.
>
> Right, but H is NOT a UTM.

The C programming language is computationally equivalent to Turing
machines for the subset of all computations that can be correctly
completed in whatever memory that it has available.

>>
>>>> The P of int main(){ P(P); } is one of these inputs therefore H
>>>> correctly decides that it never halts.
>>>
>>> P(P) in main isn't an input to anything. It's a computation. And it
>>> halts.
>>>
>>> André
>>>
>>>
>>
>>
>

--
Copyright 2021 Pete Olcott

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

On 2021-07-28 22:31, olcott wrote:
> On 7/28/2021 11:15 PM, André G. Isaak wrote:
>> On 2021-07-28 21:51, olcott wrote:
>>> On 7/28/2021 6:36 PM, André G. Isaak wrote:
>>>> On 2021-07-28 14:06, olcott wrote:
>>>>> On 7/28/2021 1:40 PM, André G. Isaak wrote:
>>>>>> On 2021-07-28 10:38, olcott wrote:
>>>>>>> On 7/28/2021 10:31 AM, André G. Isaak wrote:
>>>>>>>> On 2021-07-28 08:09, olcott wrote:
>>>>>>>>> On 7/27/2021 10:39 PM, André G. Isaak wrote:
>>>>>>>>
>>>>>>>>>> So does P(P) halt or not?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Even though the first P in the invocation sequence reaches its
>>>>>>>>> final state the fact that it only reaches its final state
>>>>>>>>> because the second P in the invocation sequence was aborted
>>>>>>>>> proves that H(P,P)==0 is correct.
>>>>>>>>
>>>>>>>> If a car only crashes because its brakes failed, that does not
>>>>>>>> imply that it didn't crash.
>>>>>>>>
>>>>>>>> If a program returns the wrong result only because it has a bug,
>>>>>>>> that does not imply that it didn't return the right answer.
>>>>>>>>
>>>>>>>> If a program only halts because the second P was aborted, that
>>>>>>>> does not imply that it didn't halt.
>>>>>>>>
>>>>>>>
>>>>>>> If an infinitely recursive sequence of function calls is aborted
>>>>>>> on the second call instead of the first call that does not mean
>>>>>>> that it was not an infinitely recursive sequence.
>>>>>>
>>>>>> But the definition of halting makes no mention of infinitely
>>>>>> recursive sequences or aborted function calls. It only requires
>>>>>> that P(P) reach a final state in a finite amount of time. P(P)
>>>>>> meets this definition.
>>>>>>
>>>>>
>>>>> If we base the decision on whether or not P halts entirely on the
>>>>> fact that it reaches its final state
>>>>
>>>> That's the DEFINITION of halting, so of course that's the only thing
>>>> we should base the decision of whether P halts on.
>>>>
>>>
>>> This is equally the definition of not halting:
>>> Every input to a simulating halt decider that only stops running when
>>> its simulation is aborted unequivocally specifies a computation that
>>> never halts.
>>
>> No, it isn't a definition of halting. At best, it is something which
>> you have proposed as a *test* for halting, but it is a broken test
>> since, at least according to you, it sometimes gives an answer that
>> does *not* correspond to the *actual* definition of halting.
>>
>
> It is computationally equivalent to not halting.

By the definition of halting, P(P) halts.

According to you, your definition leads to the conclusion that P(P)
doesn't halt.

They cannot be equivalent if they lead to different results (and I have
no idea why you use the expression 'computationally equivalent').

>>
>>>>> then we have the same situation as "This sentence is not true." It
>>>>> is indeed not true and the definition of a true sentence is whether
>>>>> or not its assertion is satisfied.
>>>>
>>>> I fail to see any parallels between P and the liar.
>>>>
>>>>> When we explicitly take into account the self-contradictory nature
>>>>> of these two cases things are not as cut-and-dried.
>>>>
>>>> There's nothing self-contradictory about it.
>>>>
>>>>> "This sentence is not true." is indeed not true yet when we apply
>>>>> this to the satisfaction of the whole sentence and not just its
>>>>> assertion
>>>>
>>>> That is gibberish.
>>>>
>>>>> then we get a contradiction. If it is true that it is not true then
>>>>> that makes is not true.
>>>>>
>>>>> It is an easily verifiable fact that the input to H(P,P) cannot
>>>>> possibly reach its final state while H remains a pure simulator.
>>>>> Because H
>>>>
>>>> But the definition of halting makes no reference to what H does at
>>>> all, nor to pure simulators. whether P(P) halts is based solely on
>>>> the behaviour of P(P).
>>>>
>>>
>>> The definition of UTM does make reference to computational
>>> equivalence forcing this statement to be necessarily true:
>>
>> Please show me a definition of UTM which makes reference to
>> computational equivalence.
>>
>
> The simulation of the TM description of TM P on input I is stipulated to
> be computationally equivalent to P(I). In an honest dialogue I would not
> have to repeat this fifty times.

I asked you to show me a *definition* of UTM which refers to
computational equivalence. The above is not a definition.

>>> Every input to a simulating halt decider that only stops running when
>>> its simulation is aborted unequivocally specifies a computation that
>>> never halts.
>>
>> A 'simulating halt decider' and UTM are different things.
>>
>
> Not while the simulating halt decider is in pure simulator mode.

UTM(P, P) halts.

You claim that your 'simulating halt decider in pure simulator mode'
doesn't halt on input P, P.

Therefore they are not the same thing.

And why does it matter what happens in a 'simulating halt decider in
pure simulator mode'?

The definition of halting is only concerned with what the computation
P(P) does, not with what happens inside a 'simulating halt decider in
pure simulator mode'.

>>>>> remains a pure simulator until after it makes its halt status
>>>>> decision then its decision that its input never halts is
>>>>> necessarily correct.
>>>>>
>>>>> That the first P in the infinitely recursive sequence reaches its
>>>>> final state after H has made its correct halt status decision is
>>>>> just like saying the liar paradox is true on the basis that its
>>>>> assertion is satisfied.
>>>>
>>>> No. That the first P reaches its final state means that P(P) halts.
>>>> The definition of halting doesn't care how or why it reaches this
>>>> state. Only that it does.
>>>
>>> So then we must conclude the the self contradictory input causes the
>>> logic of the system to be inconsistent because it proves that P halts
>>> and it proves that P never halts.
>>
>> It shows the logic of the *decider* to be inconsistent. It doesn't
>> show anything inconsistent about the definition of halting, nor does
>> it provide to treat a computation which halts as anything other than a
>> computation which halts.
>>
>
> Within the hypothesis that this is correct:
> Within the hypothesis that this is correct:
> Within the hypothesis that this is correct:
> Within the hypothesis that this is correct:
>
> Every input to a simulating halt decider that only stops running when
> its simulation is aborted unequivocally specifies a computation that
> never halts.
>
> Then the fact that the first P of int main(){ P(P); } reaches its final
> state wold seem to prove that we are getting the same contradiction as
> the liar paradox.

Bad logic on your part leads to bad results on your part. Your
'hypothesis' as you interpret it is *not* correct.

> This make perfect sense:
> garbage in  (self contradictory input)
> garbage out (contradictory result).

No. It does not make perfect sense since P(P) very clearly meets the
actual definition of halting. That definition is unambiguous and *every*
turing machine either halts or doesn't halt.

>
>> Whether P(P) halts is a question which is independent of any 'halt
>> decider'.
>>
>> H cannot decide P(P) correctly. Other partial deciders are able to
>> decide it correctly. But the definition of halting makes no reference
>> to whether any other TM can decide it correctly. It refers only to
>> whether P(P) reaches a final state in a finite number of steps. It
>> does. Therefore it halts.
>>
>>>>>>>>> Because this is too difficult to understand and accept I have
>>>>>>>>> temporarily changed the subject to refuting Rice's theorem. The
>>>>>>>>> fact that the first P reaches its final state and the second P
>>>>>>>>> is aborted can   be used as the criterion measure to
>>>>>>>>> consistently reject all and only self-contradictory inputs.
>>>>>>>>> This does refute Rices theorem.
>>>>>>>>>
>>>>>>>>>> You have on the one hand acknowledged that it does, while at
>>>>>>>>>> the same time claimed that it doesn't halt in a 'pure
>>>>>>>>>> simulator'. So if your 'global simulator' is not a pure
>>>>>>>>>> simulator, what kind of simulator is it?
>>>>>>>>
>>>>>>>> You didn't answer the above. In the past you've claimed
>>>>>>>> (falsely) that in a pure simulator, P(P) doesn't halt.
>>>>>>>>
>>>>>>>
>>>>>>> While H remains a pure simulator of its input H(P,P) its input
>>>>>>> never halts thus proving that its input never halts.
>>>>>>
>>>>>> But the definition of halting makes no mention of what happens
>>>>>> inside H, regardless of whether it remains a 'pure simulator'. It
>>>>>> only requires that the actual computation P(P) reach a final state
>>>>>> in a finite amount of time. P(P) meets this definition.
>>>>>>
>>>>>>>> Now you appear to be using your 'global simulator' to recognise
>>>>>>>> that P(P) does halt so that you can compare this with the
>>>>>>>> results of H(P, P).
>>>>>>>
>>>>>>> It is still true that H(P,P) did correctly decide that its input
>>>>>>> never halts. Because this is difficult to understand I am
>>>>>>> temporarily changing the subject to Rice's theorem.
>>>>>>
>>>>>> No, it is not. The definition of halting is clearly defined, and
>>>>>> P(P) clearly meets the definition of halting. Rice's theorem has
>>>>>> no bearing on the fact that P(P) is halting computation.
>>>>>>
>>>>>
>>>>> In this exact same way we would have to say that the liar paradox
>>>>> is true because its assertion that it is not true is fully satisfied.
>>>>
>>>> The LP's "assertion that it is not true" is *not* satisfied, fully
>>>> or otherwise.
>>>
>>> The Liar Paradox: "This sentence is not true."
>>> is indeed provably not true on the basis that it leads to a
>>> contradiction and on the basis that it specifies and infinite cycle.
>>>
>>> Only my own unique work finally resolves this:
>>>
>>> Apparently in all of the years prior to my original (2016) paper no
>>> one ever separated the analysis of propositions into their atomic
>>> units of semantic compositionality:
>>> (a) Assertion  (Boolean) //  What the expression of language claims
>>> to be True
>>> (b) Satisfied   (Boolean) //  Whether or not the expression of
>>> language is True
>>
>> You've raised this before. It's as meaningless now as it was when you
>> first suggested it.
>>
>
> No it is not. It does perfectly address the issue of the liar paradox.

On 2021-07-28 22:57, olcott wrote:
> On 7/28/2021 11:50 PM, Richard Damon wrote:
>> On 7/28/21 9:09 PM, olcott wrote:
>>> On 7/28/2021 10:36 PM, André G. Isaak wrote:
>>>> On 2021-07-28 21:25, olcott wrote:
>>>>> On 7/28/2021 6:25 PM, André G. Isaak wrote:
>>>>>> On 2021-07-28 13:07, olcott wrote:
>>>>>>
>>>>>>>> So what exactly happens for a *genuine* non-halting computation?
>>>>>>>> Your H returns 0 for non-halting and your Simulate runs forever to
>>>>>>>> confirm that this is correct? Remember that a decider, by
>>>>>>>> definition, must *halt*.
>>>>>>>>
>>>>>>>> André
>>>>>>>>
>>>>>>>
>>>>>>> When H is fully elaborated to become a full decider its divides all
>>>>>>> inputs into halting / (not-halting or PSR Error), this still
>>>>>>> refutes Rice.
>>>>>>
>>>>>> First off, that wasn't an answer to my question.
>>>>>>
>>>>>> Secondly, (not halting or PSR error) isn't a legitimate semantic
>>>>>> property so it has nothing to do with Rice.
>>>>>>
>>>>>> Halting vs. Non-Halting would be a legitimate semantic property.
>>>>>>
>>>>>> Halting vs. Non-Halting + all the cases H get wrong isn't.
>>>>>>
>>>>>> André
>>>>>>
>>>>>>
>>>>>
>>>>> This is an improvement over what anyone else has ever done:
>>>
>>>>> Every input to a simulating halt decider that only stops running when
>>>>> its simulation is aborted unequivocally specifies a computation that
>>>>> never halts.
>>>>
>>>> That's not the definition of halting. How does using the wrong
>>>> definition to get the wrong answer qualify as 'an improvement over
>>>> what anyone else has done'?
>>>>
>>>
>>> If you really think it through you may realize that because UTM(P,I) ≡
>>> P(I) it must be correct.
>>
>> Right, but H is NOT a UTM.
>
> The C programming language is computationally equivalent to Turing
> machines for the subset of all computations that can be correctly
> completed in whatever memory that it has available.

Which has absolutely nothing to do with the fact that H is not a UTM.
Nor is it the C 'equivalent' of a UTM.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 7/28/21 9:31 PM, olcott wrote:
> On 7/28/2021 11:15 PM, André G. Isaak wrote:
>> On 2021-07-28 21:51, olcott wrote:
>>> On 7/28/2021 6:36 PM, André G. Isaak wrote:
>>>> On 2021-07-28 14:06, olcott wrote:
>>>>> On 7/28/2021 1:40 PM, André G. Isaak wrote:
>>>>>> On 2021-07-28 10:38, olcott wrote:
>>>>>>> On 7/28/2021 10:31 AM, André G. Isaak wrote:
>>>>>>>> On 2021-07-28 08:09, olcott wrote:
>>>>>>>>> On 7/27/2021 10:39 PM, André G. Isaak wrote:
>>>>>>>>
>>>>>>>>>> So does P(P) halt or not?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Even though the first P in the invocation sequence reaches its
>>>>>>>>> final state the fact that it only reaches its final state
>>>>>>>>> because the second P in the invocation sequence was aborted
>>>>>>>>> proves that H(P,P)==0 is correct.
>>>>>>>>
>>>>>>>> If a car only crashes because its brakes failed, that does not
>>>>>>>> imply that it didn't crash.
>>>>>>>>
>>>>>>>> If a program returns the wrong result only because it has a bug,
>>>>>>>> that does not imply that it didn't return the right answer.
>>>>>>>>
>>>>>>>> If a program only halts because the second P was aborted, that
>>>>>>>> does not imply that it didn't halt.
>>>>>>>>
>>>>>>>
>>>>>>> If an infinitely recursive sequence of function calls is aborted
>>>>>>> on the second call instead of the first call that does not mean
>>>>>>> that it was not an infinitely recursive sequence.
>>>>>>
>>>>>> But the definition of halting makes no mention of infinitely
>>>>>> recursive sequences or aborted function calls. It only requires
>>>>>> that P(P) reach a final state in a finite amount of time. P(P)
>>>>>> meets this definition.
>>>>>>
>>>>>
>>>>> If we base the decision on whether or not P halts entirely on the
>>>>> fact that it reaches its final state
>>>>
>>>> That's the DEFINITION of halting, so of course that's the only thing
>>>> we should base the decision of whether P halts on.
>>>>
>>>
>>> This is equally the definition of not halting:
>>> Every input to a simulating halt decider that only stops running when
>>> its simulation is aborted unequivocally specifies a computation that
>>> never halts.
>>
>> No, it isn't a definition of halting. At best, it is something which
>> you have proposed as a *test* for halting, but it is a broken test
>> since, at least according to you, it sometimes gives an answer that
>> does *not* correspond to the *actual* definition of halting.
>>
>
> It is computationally equivalent to not halting.
>

No, because the simulating Halt Decider is NOT the equivalent of a UTM.

If H WAS the equivalent of a UTM, it could NEVER report a machine as
non-halting.

>>
>>>>> then we have the same situation as "This sentence is not true." It
>>>>> is indeed not true and the definition of a true sentence is whether
>>>>> or not its assertion is satisfied.
>>>>
>>>> I fail to see any parallels between P and the liar.
>>>>
>>>>> When we explicitly take into account the self-contradictory nature
>>>>> of these two cases things are not as cut-and-dried.
>>>>
>>>> There's nothing self-contradictory about it.
>>>>
>>>>> "This sentence is not true." is indeed not true yet when we apply
>>>>> this to the satisfaction of the whole sentence and not just its
>>>>> assertion
>>>>
>>>> That is gibberish.
>>>>
>>>>> then we get a contradiction. If it is true that it is not true then
>>>>> that makes is not true.
>>>>>
>>>>> It is an easily verifiable fact that the input to H(P,P) cannot
>>>>> possibly reach its final state while H remains a pure simulator.
>>>>> Because H
>>>>
>>>> But the definition of halting makes no reference to what H does at
>>>> all, nor to pure simulators. whether P(P) halts is based solely on
>>>> the behaviour of P(P).
>>>>
>>>
>>> The definition of UTM does make reference to computational
>>> equivalence forcing this statement to be necessarily true:
>>
>> Please show me a definition of UTM which makes reference to
>> computational equivalence.
>>
>
> The simulation of the TM description of TM P on input I is stipulated to
> be computationally equivalent to P(I). In an honest dialogue I would not
> have to repeat this fifty times.

yes, the UNCONDITIONAL simulation of the description is the equivalent
of running the machine.

>
>>> Every input to a simulating halt decider that only stops running when
>>> its simulation is aborted unequivocally specifies a computation that
>>> never halts.
>>
>> A 'simulating halt decider' and UTM are different things.
>>
>
> Not while the simulating halt decider is in pure simulator mode.

But as soon as it leaves that mode, is shows that it wasn't one.

There is no 'until', it is or it isn't.

A simulator until is NOT a UTM.

Maybe you would like to try to actually PROVE that, and include in your
proof how it works with the clear fact that H^(H^) does Halt by the
Definition (using running or a REAL UTM) so if your simulator until ...
generates a different answer it CAN'T be the equivalent.

This is one of your 'assumptions' that makes your logic system incorrect
and inconsistent.

>
>>>>> remains a pure simulator until after it makes its halt status
>>>>> decision then its decision that its input never halts is
>>>>> necessarily correct.
>>>>>
>>>>> That the first P in the infinitely recursive sequence reaches its
>>>>> final state after H has made its correct halt status decision is
>>>>> just like saying the liar paradox is true on the basis that its
>>>>> assertion is satisfied.
>>>>
>>>> No. That the first P reaches its final state means that P(P) halts.
>>>> The definition of halting doesn't care how or why it reaches this
>>>> state. Only that it does.
>>>
>>> So then we must conclude the the self contradictory input causes the
>>> logic of the system to be inconsistent because it proves that P halts
>>> and it proves that P never halts.
>>
>> It shows the logic of the *decider* to be inconsistent. It doesn't
>> show anything inconsistent about the definition of halting, nor does
>> it provide to treat a computation which halts as anything other than a
>> computation which halts.
>>
>
> Within the hypothesis that this is correct:
> Within the hypothesis that this is correct:
> Within the hypothesis that this is correct:
> Within the hypothesis that this is correct:

Just shows that the hypothesis is incorrect.

If I hypothesis leads to a contradiction or inconsistency, that
hypothesis is incorrect.

>
> Every input to a simulating halt decider that only stops running when
> its simulation is aborted unequivocally specifies a computation that
> never halts.

WRONG. See above. Lack of Proof is not the same as not true.

>
> Then the fact that the first P of int main(){ P(P); } reaches its final
> state wold seem to prove that we are getting the same contradiction as
> the liar paradox.

WRONG.

When you ask the RIGHT question, there is no paradox.

You get the Paradox when you ask the DESIGN question, what can H do to
give the right answer, the existance of the Paradox here just says that
there IS no machine H that can give the right answer. i.e. you have just
re-enforced Linz's proof.

>
> This make perfect sense:
> garbage in  (self contradictory input)
> garbage out (contradictory result).

WRONG.

Input is NOT 'garbage', but is a perfectly well defined input.

On 7/28/21 9:57 PM, olcott wrote:
> On 7/28/2021 11:50 PM, Richard Damon wrote:
>>
>> Right, but H is NOT a UTM.
>
> The C programming language is computationally equivalent to Turing
> machines for the subset of all computations that can be correctly
> completed in whatever memory that it has available.
>

WRONG, or maybe you just don't know what that actually means.

The C programming language is called Turing Complete, because it is
possible to represent any Turing Machine in the C language, withing the
limitations of the available memory. Note, the abstract machine in C has
an unlimited amount of memory avail via File I/O, so we can at least
theoretically handle ALL Turing Machines, practical implementations may
limit the amount of memory, but the language itself doesn't.

Also, Any C program or sub-program that represents a Computation, is the
computational equivalent of a Turing Machine.

There are C program fragments that are not Computations, or programs
that aren't computaitons because there structure doesn't properly define
the required 'input' in a way to convert to a Turing Machine, in
particular, a program that interacts with something outside of itself in
a way that is more than just being an 'input' to it.

You don't seem to understand this.

The actual issue that I point out isn't that you have this memory limit,
but that your decider H does NOT meet the requirements of a UTM, in
particular, it will decide to abort the simulation of programs,
especially programs that we can show WILL halt.

This makes it computationally different than a UTM. PERIOD. DEFINITION.

This is in fact PROVEN by the fact that when we run H^(H^) for your H
that returns non-halting for H(H^,H^) we see that H&(H^) is a halting
computation.

On 7/29/2021 12:00 AM, André G. Isaak wrote:
> On 2021-07-28 22:31, olcott wrote:
>> On 7/28/2021 11:15 PM, André G. Isaak wrote:
>>> On 2021-07-28 21:51, olcott wrote:
>>>> On 7/28/2021 6:36 PM, André G. Isaak wrote:
>>>>> On 2021-07-28 14:06, olcott wrote:
>>>>>> On 7/28/2021 1:40 PM, André G. Isaak wrote:
>>>>>>> On 2021-07-28 10:38, olcott wrote:
>>>>>>>> On 7/28/2021 10:31 AM, André G. Isaak wrote:
>>>>>>>>> On 2021-07-28 08:09, olcott wrote:
>>>>>>>>>> On 7/27/2021 10:39 PM, André G. Isaak wrote:
>>>>>>>>>
>>>>>>>>>>> So does P(P) halt or not?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Even though the first P in the invocation sequence reaches its
>>>>>>>>>> final state the fact that it only reaches its final state
>>>>>>>>>> because the second P in the invocation sequence was aborted
>>>>>>>>>> proves that H(P,P)==0 is correct.
>>>>>>>>>
>>>>>>>>> If a car only crashes because its brakes failed, that does not
>>>>>>>>> imply that it didn't crash.
>>>>>>>>>
>>>>>>>>> If a program returns the wrong result only because it has a
>>>>>>>>> bug, that does not imply that it didn't return the right answer.
>>>>>>>>>
>>>>>>>>> If a program only halts because the second P was aborted, that
>>>>>>>>> does not imply that it didn't halt.
>>>>>>>>>
>>>>>>>>
>>>>>>>> If an infinitely recursive sequence of function calls is aborted
>>>>>>>> on the second call instead of the first call that does not mean
>>>>>>>> that it was not an infinitely recursive sequence.
>>>>>>>
>>>>>>> But the definition of halting makes no mention of infinitely
>>>>>>> recursive sequences or aborted function calls. It only requires
>>>>>>> that P(P) reach a final state in a finite amount of time. P(P)
>>>>>>> meets this definition.
>>>>>>>
>>>>>>
>>>>>> If we base the decision on whether or not P halts entirely on the
>>>>>> fact that it reaches its final state
>>>>>
>>>>> That's the DEFINITION of halting, so of course that's the only
>>>>> thing we should base the decision of whether P halts on.
>>>>>
>>>>
>>>> This is equally the definition of not halting:
>>>> Every input to a simulating halt decider that only stops running
>>>> when its simulation is aborted unequivocally specifies a computation
>>>> that never halts.
>>>
>>> No, it isn't a definition of halting. At best, it is something which
>>> you have proposed as a *test* for halting, but it is a broken test
>>> since, at least according to you, it sometimes gives an answer that
>>> does *not* correspond to the *actual* definition of halting.
>>>
>>
>> It is computationally equivalent to not halting.
>
> By the definition of halting, P(P) halts.
>
> According to you, your definition leads to the conclusion that P(P)
> doesn't halt.
>
> They cannot be equivalent if they lead to different results (and I have
> no idea why you use the expression 'computationally equivalent').
>

We have two different equally correct definitions of halting that have a
contradictory result thus proving garbage in garbage out.
Self-contradictory inputs derive contradictory conclusions.

>>>
>>>>>> then we have the same situation as "This sentence is not true." It
>>>>>> is indeed not true and the definition of a true sentence is
>>>>>> whether or not its assertion is satisfied.
>>>>>
>>>>> I fail to see any parallels between P and the liar.
>>>>>
>>>>>> When we explicitly take into account the self-contradictory nature
>>>>>> of these two cases things are not as cut-and-dried.
>>>>>
>>>>> There's nothing self-contradictory about it.
>>>>>
>>>>>> "This sentence is not true." is indeed not true yet when we apply
>>>>>> this to the satisfaction of the whole sentence and not just its
>>>>>> assertion
>>>>>
>>>>> That is gibberish.
>>>>>
>>>>>> then we get a contradiction. If it is true that it is not true
>>>>>> then that makes is not true.
>>>>>>
>>>>>> It is an easily verifiable fact that the input to H(P,P) cannot
>>>>>> possibly reach its final state while H remains a pure simulator.
>>>>>> Because H
>>>>>
>>>>> But the definition of halting makes no reference to what H does at
>>>>> all, nor to pure simulators. whether P(P) halts is based solely on
>>>>> the behaviour of P(P).
>>>>>
>>>>
>>>> The definition of UTM does make reference to computational
>>>> equivalence forcing this statement to be necessarily true:
>>>
>>> Please show me a definition of UTM which makes reference to
>>> computational equivalence.
>>>
>>
>> The simulation of the TM description of TM P on input I is stipulated
>> to be computationally equivalent to P(I). In an honest dialogue I
>> would not have to repeat this fifty times.
>
> I asked you to show me a *definition* of UTM which refers to
> computational equivalence. The above is not a definition.

Perhaps you are proving that you are unqualified to evaluate my work?
....anything which can be “computed”, can also be computed by that one
universal machine. Conversely, any problem that is not computable by the
universal machine is considered to be uncomputable.
https://plato.stanford.edu/entries/turing-machine/#TuriUnivMach

>>>> Every input to a simulating halt decider that only stops running
>>>> when its simulation is aborted unequivocally specifies a computation
>>>> that never halts.
>>>
>>> A 'simulating halt decider' and UTM are different things.
>>>
>>
>> Not while the simulating halt decider is in pure simulator mode.
>
> UTM(P, P) halts.
>
> You claim that your 'simulating halt decider in pure simulator mode'
> doesn't halt on input P, P.
>

Which is another way of saying:
Every input to a simulating halt decider that only stops running when
its simulation is aborted unequivocally specifies a computation that
never halts.

> Therefore they are not the same thing.
>
> And why does it matter what happens in a 'simulating halt decider in
> pure simulator mode'?
>
> The definition of halting is only concerned with what the computation
> P(P) does, not with what happens inside a 'simulating halt decider in
> pure simulator mode'.
>

None-the-less my definitions are computationally equivalent to the
standard ones on this basis: UTM(P,I) ≡ P(I)

That you deny this seems to indicate that you do not know the subject
matter well enough to be qualified to evaluate my work.

>>>>>> remains a pure simulator until after it makes its halt status
>>>>>> decision then its decision that its input never halts is
>>>>>> necessarily correct.
>>>>>>
>>>>>> That the first P in the infinitely recursive sequence reaches its
>>>>>> final state after H has made its correct halt status decision is
>>>>>> just like saying the liar paradox is true on the basis that its
>>>>>> assertion is satisfied.
>>>>>
>>>>> No. That the first P reaches its final state means that P(P) halts.
>>>>> The definition of halting doesn't care how or why it reaches this
>>>>> state. Only that it does.
>>>>
>>>> So then we must conclude the the self contradictory input causes the
>>>> logic of the system to be inconsistent because it proves that P
>>>> halts and it proves that P never halts.
>>>
>>> It shows the logic of the *decider* to be inconsistent. It doesn't
>>> show anything inconsistent about the definition of halting, nor does
>>> it provide to treat a computation which halts as anything other than
>>> a computation which halts.
>>>
>>
>> Within the hypothesis that this is correct:
>> Within the hypothesis that this is correct:
>> Within the hypothesis that this is correct:
>> Within the hypothesis that this is correct:
>>
>> Every input to a simulating halt decider that only stops running when
>> its simulation is aborted unequivocally specifies a computation that
>> never halts.
>>
>> Then the fact that the first P of int main(){ P(P); } reaches its
>> final state wold seem to prove that we are getting the same
>> contradiction as the liar paradox.
>
> Bad logic on your part leads to bad results on your part. Your
> 'hypothesis' as you interpret it is *not* correct.
>
>> This make perfect sense:
>> garbage in  (self contradictory input)
>> garbage out (contradictory result).
>
> No. It does not make perfect sense since P(P) very clearly meets the
> actual definition of halting.

On 7/29/2021 12:10 AM, André G. Isaak wrote:
> On 2021-07-28 22:57, olcott wrote:
>> On 7/28/2021 11:50 PM, Richard Damon wrote:
>>> On 7/28/21 9:09 PM, olcott wrote:
>>>> On 7/28/2021 10:36 PM, André G. Isaak wrote:
>>>>> On 2021-07-28 21:25, olcott wrote:
>>>>>> On 7/28/2021 6:25 PM, André G. Isaak wrote:
>>>>>>> On 2021-07-28 13:07, olcott wrote:
>>>>>>>
>>>>>>>>> So what exactly happens for a *genuine* non-halting computation?
>>>>>>>>> Your H returns 0 for non-halting and your Simulate runs forever to
>>>>>>>>> confirm that this is correct? Remember that a decider, by
>>>>>>>>> definition, must *halt*.
>>>>>>>>>
>>>>>>>>> André
>>>>>>>>>
>>>>>>>>
>>>>>>>> When H is fully elaborated to become a full decider its divides all
>>>>>>>> inputs into halting / (not-halting or PSR Error), this still
>>>>>>>> refutes Rice.
>>>>>>>
>>>>>>> First off, that wasn't an answer to my question.
>>>>>>>
>>>>>>> Secondly, (not halting or PSR error) isn't a legitimate semantic
>>>>>>> property so it has nothing to do with Rice.
>>>>>>>
>>>>>>> Halting vs. Non-Halting would be a legitimate semantic property.
>>>>>>>
>>>>>>> Halting vs. Non-Halting + all the cases H get wrong isn't.
>>>>>>>
>>>>>>> André
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> This is an improvement over what anyone else has ever done:
>>>>
>>>>>> Every input to a simulating halt decider that only stops running when
>>>>>> its simulation is aborted unequivocally specifies a computation that
>>>>>> never halts.
>>>>>
>>>>> That's not the definition of halting. How does using the wrong
>>>>> definition to get the wrong answer qualify as 'an improvement over
>>>>> what anyone else has done'?
>>>>>
>>>>
>>>> If you really think it through you may realize that because UTM(P,I) ≡
>>>> P(I) it must be correct.
>>>
>>> Right, but H is NOT a UTM.
>>
>> The C programming language is computationally equivalent to Turing
>> machines for the subset of all computations that can be correctly
>> completed in whatever memory that it has available.
>
> Which has absolutely nothing to do with the fact that H is not a UTM.
> Nor is it the C 'equivalent' of a UTM.
>
> André
>

While H is in pure simulator mode it is computationally equivalent to a
UTM.

--
Copyright 2021 Pete Olcott

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

On 7/28/2021 11:15 PM, André G. Isaak wrote:
> On 2021-07-28 21:51, olcott wrote:

>> This is equally the definition of not halting:
>> Every input to a simulating halt decider that only stops running when
>> its simulation is aborted unequivocally specifies a computation that
>> never halts.
>
> No, it isn't a definition of halting. At best, it is something which you
> have proposed as a *test* for halting, but it is a broken test since, at
> least according to you, it sometimes gives an answer that does *not*
> correspond to the *actual* definition of halting.
Try and provide a counter-example of an input to H that is a halting
computation even though it never halts unless its simulation is aborted.

--
Copyright 2021 Pete Olcott

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

On 7/29/21 11:07 AM, olcott wrote:

> While H is in pure simulator mode it is computationally equivalent to a
> UTM.
>

And, as soon as it leaves that mode, it shows that it wasn't
computationally equivalent.

There is no such thing as computationally equivalent until.

You FAIL on definitons.

On 7/29/21 10:39 AM, olcott wrote:
> On 7/29/2021 12:00 AM, André G. Isaak wrote:
>> On 2021-07-28 22:31, olcott wrote:
>>> On 7/28/2021 11:15 PM, André G. Isaak wrote:
>>>> On 2021-07-28 21:51, olcott wrote:
>>>>> On 7/28/2021 6:36 PM, André G. Isaak wrote:
>>>>>> On 2021-07-28 14:06, olcott wrote:
>>>>>>> On 7/28/2021 1:40 PM, André G. Isaak wrote:
>>>>>>>> On 2021-07-28 10:38, olcott wrote:
>>>>>>>>> On 7/28/2021 10:31 AM, André G. Isaak wrote:
>>>>>>>>>> On 2021-07-28 08:09, olcott wrote:
>>>>>>>>>>> On 7/27/2021 10:39 PM, André G. Isaak wrote:
>>>>>>>>>>
>>>>>>>>>>>> So does P(P) halt or not?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Even though the first P in the invocation sequence reaches
>>>>>>>>>>> its final state the fact that it only reaches its final state
>>>>>>>>>>> because the second P in the invocation sequence was aborted
>>>>>>>>>>> proves that H(P,P)==0 is correct.
>>>>>>>>>>
>>>>>>>>>> If a car only crashes because its brakes failed, that does not
>>>>>>>>>> imply that it didn't crash.
>>>>>>>>>>
>>>>>>>>>> If a program returns the wrong result only because it has a
>>>>>>>>>> bug, that does not imply that it didn't return the right answer.
>>>>>>>>>>
>>>>>>>>>> If a program only halts because the second P was aborted, that
>>>>>>>>>> does not imply that it didn't halt.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> If an infinitely recursive sequence of function calls is
>>>>>>>>> aborted on the second call instead of the first call that does
>>>>>>>>> not mean that it was not an infinitely recursive sequence.
>>>>>>>>
>>>>>>>> But the definition of halting makes no mention of infinitely
>>>>>>>> recursive sequences or aborted function calls. It only requires
>>>>>>>> that P(P) reach a final state in a finite amount of time. P(P)
>>>>>>>> meets this definition.
>>>>>>>>
>>>>>>>
>>>>>>> If we base the decision on whether or not P halts entirely on the
>>>>>>> fact that it reaches its final state
>>>>>>
>>>>>> That's the DEFINITION of halting, so of course that's the only
>>>>>> thing we should base the decision of whether P halts on.
>>>>>>
>>>>>
>>>>> This is equally the definition of not halting:
>>>>> Every input to a simulating halt decider that only stops running
>>>>> when its simulation is aborted unequivocally specifies a
>>>>> computation that never halts.
>>>>
>>>> No, it isn't a definition of halting. At best, it is something which
>>>> you have proposed as a *test* for halting, but it is a broken test
>>>> since, at least according to you, it sometimes gives an answer that
>>>> does *not* correspond to the *actual* definition of halting.
>>>>
>>>
>>> It is computationally equivalent to not halting.
>>
>> By the definition of halting, P(P) halts.
>>
>> According to you, your definition leads to the conclusion that P(P)
>> doesn't halt.
>>
>> They cannot be equivalent if they lead to different results (and I
>> have no idea why you use the expression 'computationally equivalent').
>>
>
> We have two different equally correct definitions of halting that have a
> contradictory result thus proving garbage in garbage out.
> Self-contradictory inputs derive contradictory conclusions.

No, you DON'T have two equally correct definitions.

Real Definition: P(I) is halting if when run it reaches a Halting state
in a finite number of steps, and non-halting if it NEVER reaches a
halting state for any finite number of steps.

Real Alternate Definition: P(I) is halting if a PURE SIMULATION of P(I)
reaches a Halting State in a finite number of steps, and non-halting if
it never reaches a halting state for any finite number of steps.

Your 'Alternate Definition' is wrong because a Halting decider that is a
pure simulator until ... is NOT a Pure Simulator, nor is it
computaitonally equivalent to one, unless it actually never aborts its
simulation and thus never can properly decide a non-halting simulation.

>
>>>>
>>>>>>> then we have the same situation as "This sentence is not true."
>>>>>>> It is indeed not true and the definition of a true sentence is
>>>>>>> whether or not its assertion is satisfied.
>>>>>>
>>>>>> I fail to see any parallels between P and the liar.
>>>>>>
>>>>>>> When we explicitly take into account the self-contradictory
>>>>>>> nature of these two cases things are not as cut-and-dried.
>>>>>>
>>>>>> There's nothing self-contradictory about it.
>>>>>>
>>>>>>> "This sentence is not true." is indeed not true yet when we apply
>>>>>>> this to the satisfaction of the whole sentence and not just its
>>>>>>> assertion
>>>>>>
>>>>>> That is gibberish.
>>>>>>
>>>>>>> then we get a contradiction. If it is true that it is not true
>>>>>>> then that makes is not true.
>>>>>>>
>>>>>>> It is an easily verifiable fact that the input to H(P,P) cannot
>>>>>>> possibly reach its final state while H remains a pure simulator.
>>>>>>> Because H
>>>>>>
>>>>>> But the definition of halting makes no reference to what H does at
>>>>>> all, nor to pure simulators. whether P(P) halts is based solely on
>>>>>> the behaviour of P(P).
>>>>>>
>>>>>
>>>>> The definition of UTM does make reference to computational
>>>>> equivalence forcing this statement to be necessarily true:
>>>>
>>>> Please show me a definition of UTM which makes reference to
>>>> computational equivalence.
>>>>
>>>
>>> The simulation of the TM description of TM P on input I is stipulated
>>> to be computationally equivalent to P(I). In an honest dialogue I
>>> would not have to repeat this fifty times.
>>
>> I asked you to show me a *definition* of UTM which refers to
>> computational equivalence. The above is not a definition.
>
> Perhaps you are proving that you are unqualified to evaluate my work?
> ...anything which can be “computed”, can also be computed by that one
> universal machine. Conversely, any problem that is not computable by the
> universal machine is considered to be uncomputable.
> https://plato.stanford.edu/entries/turing-machine/#TuriUnivMach
>

Be sure you use the right definition of Computation, because you above
statement is actually false. A 'Computation' is not anything a 'Computer
does'

Computers can actually do many things that are not Computations in
themselves, and as such can do some things that a Turing Machine doesn't do.

For instance, if a Computer is talking to another computer sending data
and getting results back from the other computer, doing some more
processing on it sending more messages and getting more responces and so
on, that computer isn't doing a Computation. Per haps each individual
processing is a Computation, or the system including BOTH computers
might be a Computation, but the 'interactive session' itself isn't one.

A Computation requires being able to gather ALL the data that affect the
result generated up front, 'run' the computation, and generate results.

In general, a COMPLETE ISOLATED computer system will perform Computation
as its whole. It is quite possible that sub-pieces might not qualify,
unless they can gather ALL of the data that affects it to be called the
input and ALL the algorithm used to process it.

On 7/29/21 11:15 AM, olcott wrote:
> On 7/28/2021 11:15 PM, André G. Isaak wrote:
>> On 2021-07-28 21:51, olcott wrote:
>
>>> This is equally the definition of not halting:
>>> Every input to a simulating halt decider that only stops running when
>>> its simulation is aborted unequivocally specifies a computation that
>>> never halts.
>>
>> No, it isn't a definition of halting. At best, it is something which
>> you have proposed as a *test* for halting, but it is a broken test
>> since, at least according to you, it sometimes gives an answer that
>> does *not* correspond to the *actual* definition of halting.
> Try and provide a counter-example of an input to H that is a halting
> computation even though it never halts unless its simulation is aborted.
>

But that isn't the claim you made.

You claim that this applies to the simulation of a simulating halt decider.

The counter to THAT is H^(H^), which DOES Halt when run, and DOES Halt
when simulated by pure Simulator, but which the H that it is based on
will abort before it reaches its halting state, BECAUSE H aborts it
incorrectly.

Yes, if UTM(P,I) never halts, then P(I) is non-halting.

But since UTM(H^,H^) halts, then H is incorrect in saying the H(H^,H^)
is correct in deciding that H^(H^) is non-halting.

You are applying improper logic to make that claim.

One BIG part is that you are ignoring that H^ is dependent on the
algorithm of H, and thus any argument that is based on looking at
classes of H, doesn't apply to any one specific H^, but is making
arguments about a similar set of classes og H^.

That no H can simulate H^ to a halting state just proves that no H can
prove that its H^ halts. Not being able to prove is not proof that it
doesn't, so we can NOT claim that no H^ halts. THAT is an UNSOUND
conclusion.

On 2021-07-29 11:39, olcott wrote:
> On 7/29/2021 12:00 AM, André G. Isaak wrote:
>> On 2021-07-28 22:31, olcott wrote:
>>> On 7/28/2021 11:15 PM, André G. Isaak wrote:
>>>> On 2021-07-28 21:51, olcott wrote:
>>>>> On 7/28/2021 6:36 PM, André G. Isaak wrote:
>>>>>> On 2021-07-28 14:06, olcott wrote:
>>>>>>> On 7/28/2021 1:40 PM, André G. Isaak wrote:
>>>>>>>> On 2021-07-28 10:38, olcott wrote:
>>>>>>>>> On 7/28/2021 10:31 AM, André G. Isaak wrote:
>>>>>>>>>> On 2021-07-28 08:09, olcott wrote:
>>>>>>>>>>> On 7/27/2021 10:39 PM, André G. Isaak wrote:
>>>>>>>>>>
>>>>>>>>>>>> So does P(P) halt or not?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Even though the first P in the invocation sequence reaches
>>>>>>>>>>> its final state the fact that it only reaches its final state
>>>>>>>>>>> because the second P in the invocation sequence was aborted
>>>>>>>>>>> proves that H(P,P)==0 is correct.
>>>>>>>>>>
>>>>>>>>>> If a car only crashes because its brakes failed, that does not
>>>>>>>>>> imply that it didn't crash.
>>>>>>>>>>
>>>>>>>>>> If a program returns the wrong result only because it has a
>>>>>>>>>> bug, that does not imply that it didn't return the right answer.
>>>>>>>>>>
>>>>>>>>>> If a program only halts because the second P was aborted, that
>>>>>>>>>> does not imply that it didn't halt.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> If an infinitely recursive sequence of function calls is
>>>>>>>>> aborted on the second call instead of the first call that does
>>>>>>>>> not mean that it was not an infinitely recursive sequence.
>>>>>>>>
>>>>>>>> But the definition of halting makes no mention of infinitely
>>>>>>>> recursive sequences or aborted function calls. It only requires
>>>>>>>> that P(P) reach a final state in a finite amount of time. P(P)
>>>>>>>> meets this definition.
>>>>>>>>
>>>>>>>
>>>>>>> If we base the decision on whether or not P halts entirely on the
>>>>>>> fact that it reaches its final state
>>>>>>
>>>>>> That's the DEFINITION of halting, so of course that's the only
>>>>>> thing we should base the decision of whether P halts on.
>>>>>>
>>>>>
>>>>> This is equally the definition of not halting:
>>>>> Every input to a simulating halt decider that only stops running
>>>>> when its simulation is aborted unequivocally specifies a
>>>>> computation that never halts.
>>>>
>>>> No, it isn't a definition of halting. At best, it is something which
>>>> you have proposed as a *test* for halting, but it is a broken test
>>>> since, at least according to you, it sometimes gives an answer that
>>>> does *not* correspond to the *actual* definition of halting.
>>>>
>>>
>>> It is computationally equivalent to not halting.
>>
>> By the definition of halting, P(P) halts.
>>
>> According to you, your definition leads to the conclusion that P(P)
>> doesn't halt.
>>
>> They cannot be equivalent if they lead to different results (and I
>> have no idea why you use the expression 'computationally equivalent').
>>
>
> We have two different equally correct definitions of halting that have a
> contradictory result thus proving garbage in garbage out.
> Self-contradictory inputs derive contradictory conclusions.

No, we don't have two equally correct definitions. We have the actual
definition and we have your incorrect definition.

>>>>
>>>>>>> then we have the same situation as "This sentence is not true."
>>>>>>> It is indeed not true and the definition of a true sentence is
>>>>>>> whether or not its assertion is satisfied.
>>>>>>
>>>>>> I fail to see any parallels between P and the liar.
>>>>>>
>>>>>>> When we explicitly take into account the self-contradictory
>>>>>>> nature of these two cases things are not as cut-and-dried.
>>>>>>
>>>>>> There's nothing self-contradictory about it.
>>>>>>
>>>>>>> "This sentence is not true." is indeed not true yet when we apply
>>>>>>> this to the satisfaction of the whole sentence and not just its
>>>>>>> assertion
>>>>>>
>>>>>> That is gibberish.
>>>>>>
>>>>>>> then we get a contradiction. If it is true that it is not true
>>>>>>> then that makes is not true.
>>>>>>>
>>>>>>> It is an easily verifiable fact that the input to H(P,P) cannot
>>>>>>> possibly reach its final state while H remains a pure simulator.
>>>>>>> Because H
>>>>>>
>>>>>> But the definition of halting makes no reference to what H does at
>>>>>> all, nor to pure simulators. whether P(P) halts is based solely on
>>>>>> the behaviour of P(P).
>>>>>>
>>>>>
>>>>> The definition of UTM does make reference to computational
>>>>> equivalence forcing this statement to be necessarily true:
>>>>
>>>> Please show me a definition of UTM which makes reference to
>>>> computational equivalence.
>>>>
>>>
>>> The simulation of the TM description of TM P on input I is stipulated
>>> to be computationally equivalent to P(I). In an honest dialogue I
>>> would not have to repeat this fifty times.
>>
>> I asked you to show me a *definition* of UTM which refers to
>> computational equivalence. The above is not a definition.
>
> Perhaps you are proving that you are unqualified to evaluate my work?
> ...anything which can be “computed”, can also be computed by that one
> universal machine. Conversely, any problem that is not computable by the
> universal machine is considered to be uncomputable.
> https://plato.stanford.edu/entries/turing-machine/#TuriUnivMach

Once again, you claimed that the *definition* of UTM makes reference to
computational equivalence. I am asking you to provide a reference to a
source which *defines* UTM in a way which uses the term 'computational
equivalence'.

>>>>> Every input to a simulating halt decider that only stops running
>>>>> when its simulation is aborted unequivocally specifies a
>>>>> computation that never halts.
>>>>
>>>> A 'simulating halt decider' and UTM are different things.
>>>>
>>>
>>> Not while the simulating halt decider is in pure simulator mode.
>>
>> UTM(P, P) halts.
>>
>> You claim that your 'simulating halt decider in pure simulator mode'
>> doesn't halt on input P, P.
>>
>
> Which is another way of saying:
> Every input to a simulating halt decider that only stops running when
> its simulation is aborted unequivocally specifies a computation that
> never halts.

No it isn't another way of saying that since it says something entirely
different.

>> Therefore they are not the same thing.
>>
>> And why does it matter what happens in a 'simulating halt decider in
>> pure simulator mode'?
>>
>> The definition of halting is only concerned with what the computation
>> P(P) does, not with what happens inside a 'simulating halt decider in
>> pure simulator mode'.
>>
>
> None-the-less my definitions are computationally equivalent to the
> standard ones on this basis: UTM(P,I) ≡ P(I)

On 2021-07-29 12:07, olcott wrote:
> On 7/29/2021 12:10 AM, André G. Isaak wrote:
>> On 2021-07-28 22:57, olcott wrote:
>>> On 7/28/2021 11:50 PM, Richard Damon wrote:
>>>> On 7/28/21 9:09 PM, olcott wrote:
>>>>> On 7/28/2021 10:36 PM, André G. Isaak wrote:
>>>>>> On 2021-07-28 21:25, olcott wrote:
>>>>>>> On 7/28/2021 6:25 PM, André G. Isaak wrote:
>>>>>>>> On 2021-07-28 13:07, olcott wrote:
>>>>>>>>
>>>>>>>>>> So what exactly happens for a *genuine* non-halting computation?
>>>>>>>>>> Your H returns 0 for non-halting and your Simulate runs
>>>>>>>>>> forever to
>>>>>>>>>> confirm that this is correct? Remember that a decider, by
>>>>>>>>>> definition, must *halt*.
>>>>>>>>>>
>>>>>>>>>> André
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> When H is fully elaborated to become a full decider its divides
>>>>>>>>> all
>>>>>>>>> inputs into halting / (not-halting or PSR Error), this still
>>>>>>>>> refutes Rice.
>>>>>>>>
>>>>>>>> First off, that wasn't an answer to my question.
>>>>>>>>
>>>>>>>> Secondly, (not halting or PSR error) isn't a legitimate semantic
>>>>>>>> property so it has nothing to do with Rice.
>>>>>>>>
>>>>>>>> Halting vs. Non-Halting would be a legitimate semantic property.
>>>>>>>>
>>>>>>>> Halting vs. Non-Halting + all the cases H get wrong isn't.
>>>>>>>>
>>>>>>>> André
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> This is an improvement over what anyone else has ever done:
>>>>>
>>>>>>> Every input to a simulating halt decider that only stops running
>>>>>>> when
>>>>>>> its simulation is aborted unequivocally specifies a computation that
>>>>>>> never halts.
>>>>>>
>>>>>> That's not the definition of halting. How does using the wrong
>>>>>> definition to get the wrong answer qualify as 'an improvement over
>>>>>> what anyone else has done'?
>>>>>>
>>>>>
>>>>> If you really think it through you may realize that because UTM(P,I) ≡
>>>>> P(I) it must be correct.
>>>>
>>>> Right, but H is NOT a UTM.
>>>
>>> The C programming language is computationally equivalent to Turing
>>> machines for the subset of all computations that can be correctly
>>> completed in whatever memory that it has available.
>>
>> Which has absolutely nothing to do with the fact that H is not a UTM.
>> Nor is it the C 'equivalent' of a UTM.
>>
>> André
>>
>
> While H is in pure simulator mode it is computationally equivalent to a
> UTM.

No. It isn't.

UTM(P, P) *will* halt.

In 'pure simulator mode', your H would behave as a UTM *if* it were the
case that P's behaviour was unchanged, but everytime you talk about H in
'pure simulator mode' you appear to mean that *both* the behaviour of H
and the behaviour of P are affected.

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 2021-07-29 12:15, olcott wrote:
> On 7/28/2021 11:15 PM, André G. Isaak wrote:
>> On 2021-07-28 21:51, olcott wrote:
>
>>> This is equally the definition of not halting:
>>> Every input to a simulating halt decider that only stops running when
>>> its simulation is aborted unequivocally specifies a computation that
>>> never halts.
>>
>> No, it isn't a definition of halting. At best, it is something which
>> you have proposed as a *test* for halting, but it is a broken test
>> since, at least according to you, it sometimes gives an answer that
>> does *not* correspond to the *actual* definition of halting.
> Try and provide a counter-example of an input to H that is a halting
> computation even though it never halts unless its simulation is aborted.

P(P) is a counterexample to your H because your H claims that P(P) won't
halt without its simulation being aborted when clearly this is not the
case. P(P) halts when run independently. And when run independently P(P)
isn't being simulated, so it can't have its simulation aborted.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 7/29/2021 2:55 PM, André G. Isaak wrote:
> On 2021-07-29 12:15, olcott wrote:
>> On 7/28/2021 11:15 PM, André G. Isaak wrote:
>>> On 2021-07-28 21:51, olcott wrote:
>>
>>>> This is equally the definition of not halting:
>>>> Every input to a simulating halt decider that only stops running
>>>> when its simulation is aborted unequivocally specifies a computation
>>>> that never halts.
>>>
>>> No, it isn't a definition of halting. At best, it is something which
>>> you have proposed as a *test* for halting, but it is a broken test
>>> since, at least according to you, it sometimes gives an answer that
>>> does *not* correspond to the *actual* definition of halting.

>> Try and provide a counter-example of an input to H that is a halting
>> computation even though it never halts unless its simulation is aborted.
>
> P(P) is a counterexample to your H because your H claims that P(P) won't

Try and provide a

counter-example of an input to H
counter-example of an input to H
counter-example of an input to H
counter-example of an input to H
counter-example of an input to H

that is a halting
computation even though it never halts unless its simulation is aborted.

> halt without its simulation being aborted when clearly this is not the
> case. P(P) halts when run independently. And when run independently P(P)
> isn't being simulated, so it can't have its simulation aborted.
>
> André
>

--
Copyright 2021 Pete Olcott

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

On 2021-07-29 16:50, olcott wrote:
> On 7/29/2021 2:55 PM, André G. Isaak wrote:
>> On 2021-07-29 12:15, olcott wrote:
>>> On 7/28/2021 11:15 PM, André G. Isaak wrote:
>>>> On 2021-07-28 21:51, olcott wrote:
>>>
>>>>> This is equally the definition of not halting:
>>>>> Every input to a simulating halt decider that only stops running
>>>>> when its simulation is aborted unequivocally specifies a
>>>>> computation that never halts.
>>>>
>>>> No, it isn't a definition of halting. At best, it is something which
>>>> you have proposed as a *test* for halting, but it is a broken test
>>>> since, at least according to you, it sometimes gives an answer that
>>>> does *not* correspond to the *actual* definition of halting.
>
>>> Try and provide a counter-example of an input to H that is a halting
>>> computation even though it never halts unless its simulation is aborted.
>>
>> P(P) is a counterexample to your H because your H claims that P(P) won't
>
> Try and provide a
>
> counter-example of an input to H
> counter-example of an input to H
> counter-example of an input to H
> counter-example of an input to H
> counter-example of an input to H
>
> that is a halting
> computation even though it never halts unless its simulation is aborted.

No computation that *truly* wouldn't halt unless its simulation is
aborted would be a halting computatation. I don't think anyone disputes
that. But your H doesn't actually test for this condition since it
claims that computations such as P(P) which *are* halting computations
need to have their simulations aborted in order for them to halt.

But this isn't a viable *definition* of halting since halting is a
property of computations which exists *independently* of any halt
decider or simulator, so a definition of halting shouldn't refer to such
things.

The definition of halting is that a computation halts if it reaches a
final state in a finite number of steps. There is absolutely no need for
any other definition, and there's definitely something wrong with any
"proof" which *requires* a different definition.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 7/29/21 3:50 PM, olcott wrote:
> On 7/29/2021 2:55 PM, André G. Isaak wrote:
>> On 2021-07-29 12:15, olcott wrote:
>>> On 7/28/2021 11:15 PM, André G. Isaak wrote:
>>>> On 2021-07-28 21:51, olcott wrote:
>>>
>>>>> This is equally the definition of not halting:
>>>>> Every input to a simulating halt decider that only stops running
>>>>> when its simulation is aborted unequivocally specifies a
>>>>> computation that never halts.
>>>>
>>>> No, it isn't a definition of halting. At best, it is something which
>>>> you have proposed as a *test* for halting, but it is a broken test
>>>> since, at least according to you, it sometimes gives an answer that
>>>> does *not* correspond to the *actual* definition of halting.
>
>>> Try and provide a counter-example of an input to H that is a halting
>>> computation even though it never halts unless its simulation is aborted.
>>
>> P(P) is a counterexample to your H because your H claims that P(P) won't
>
> Try and provide a
>
> counter-example of an input to H
> counter-example of an input to H
> counter-example of an input to H
> counter-example of an input to H
> counter-example of an input to H
>
> that is a halting
> computation even though it never halts unless its simulation is aborted.
>

I will point out Scarecrow (calling you that as you like to use
straw-men so much), the NO ONE has claimed that there exists a machine
that halts, but its simulation is a REAL PURE SIMULATOR doesn't halt.

What has been pointed out is that your 'Simulating Halt Decider' that
claims to be a 'Pure Simulator until it makes its decision', doen't
qualify as a REAL PURE SIMULATOR, BECAUSE at some point it CEASES to be one.

Your H does get wrong that case of H^(H^) because it says it is
non-halting, but by the REAL definition, H^(H^) does Halt.

The fact that H has aborted it before it gets to that point, as we can
tell by comparing the trace of H^(H^) when run as an actual Machine, and
the trace we get out of H(H^,H^), we see that H sees EXACTLY the same
trace, up to the point that it aborts H^, so the argument that this
trace pattern is somehow 'proof' that it is non-halting is FALSE.