On 7/28/21 12:07 PM, olcott wrote:
> On 7/28/2021 1:47 PM, André G. Isaak wrote:
>> On 2021-07-28 12:35, olcott wrote:
>>> On 7/28/2021 11:38 AM, 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.
>>>>
>>>>>> 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.
>>>>
>>>>> 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.
>>>>
>>>>> 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.
>>>>
>>>>> simulator is your 'global simulator' which, apparently, correctly
>>>>> detects that P(P) halts?
>>>>>
>>>>
>>>> It correctly detects that the P of int main() { P(P); } reaches its
>>>> final state.
>>>>
>>>>>>>> There will not actually be any function call Simulate(P,P) per
>>>>>>>> say and this code has not been designed yet.
>>>>>>>>
>>>>>>>> The very easy part that you should have understood many messages
>>>>>>>> ago is that when the code somehow determines that the halt
>>>>>>>> decider return value is not consistent with the behavior of P
>>>>>>>> this is freaking used to freaking refute Rice.
>>>>>>> The problem is that H isn't doing the detecting. To the extent
>>>>>>> that what you say makes sense it is some other software which
>>>>>>> tests the result of H(P,P) against the result of your 'global
>>>>>>> simulator'. But *that* piece of software will have its *own*
>>>>>>> H_Hat which will be just as susceptible to the Linz proof as your H.
>>>>>>>
>>>>>>> Every putative halt decider has its *own* H_Hat which it will not
>>>>>>> be able to decide, which is perfectly in line with Rice.
>>>>>>>
>>>>>>> André
>>>>>>
>>>>>> That each of these putative halt deciders recognize and reject all
>>>>>> and only self-contradictory inputs refutes Rice.
>>>>>
>>>>> And you've demonstrated this where, exactly?
>>>>>
>>>>> As far as I can tell your H doesn't reject anything. It simply gets
>>>>> some cases wrong.
>>>>>
>>>>
>>>> The code to reject inputs has not even been fully designed yet.
>>>> It is easy to see that the criteria for this already exists.
>>>>
>>>>> Your H(P, P) claims that P(P) doesn't halt, which is wrong.
>>>>>
>>>>
>>>> The input to H(P,P) never halts while H remains in pure simulator mode.
>>>>
>>>>> You claim that you can reject this based on the fact that it
>>>>> doesn't match which your 'global simulator' concludes.
>>>>>
>>>>> But that means that neither the global simulator nor H on their own
>>>>> are capable of rejecting anything.
>>>>>
>>>>
>>>> So what?
>>>>
>>>>> Whatever code is comparing these two values is what is doing the
>>>>> rejecting. And we can construct from *that* piece of code another
>>>>> H_Hat which *that* piece of code cannot answer correctly.
>>>>>
>>>>> André
>>>>>
>>>>
>>>
>>> int Simulate(u32 P, u32 I)
>>> {
>>>    ((int(*)(int))P)(I);
>>>    return 1;
>>> }
>>>
>>> void P(u32 x)
>>> {
>>>    if (H(x, x))
>>>      HERE: goto HERE;
>>> }
>>>
>>> u32 PSR_Decider(u32 P, u32 I)
>>> {
>>>    if (Simulate(P, I) != H(P, I))
>>>      return 1;
>>>    return 0;
>>> }
>>>
>>> int main()
>>> {
>>>    Output("PSR_Decider = ", PSR_Decider((u32)P, (u32)P));
>>> }
>>
>> 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.
>

Except that PRS_Decider won't return, because Simulate won't return from
a REAL non-halting computation.

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

When we explicitly take into account the self-contradictory nature of
these two cases things are not as cut-and-dried.

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

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

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

As Ben has unequivocally agreed any simulation that only halts because
it was aborted is a non-halting computation.

>>> simulator is your 'global simulator' which, apparently, correctly
>>> detects that P(P) halts?
>>>
>>
>> It correctly detects that the P of int main() { P(P); } reaches its
>> final state.
>
> Which means that P(P) meets the definition of halting and is therefore a
> halting computation.
>
>>>>>> There will not actually be any function call Simulate(P,P) per say
>>>>>> and this code has not been designed yet.
>>>>>>
>>>>>> The very easy part that you should have understood many messages
>>>>>> ago is that when the code somehow determines that the halt decider
>>>>>> return value is not consistent with the behavior of P this is
>>>>>> freaking used to freaking refute Rice.
>>>>> The problem is that H isn't doing the detecting. To the extent that
>>>>> what you say makes sense it is some other software which tests the
>>>>> result of H(P,P) against the result of your 'global simulator'. But
>>>>> *that* piece of software will have its *own* H_Hat which will be
>>>>> just as susceptible to the Linz proof as your H.
>>>>>
>>>>> Every putative halt decider has its *own* H_Hat which it will not
>>>>> be able to decide, which is perfectly in line with Rice.
>>>>>
>>>>> André
>>>>
>>>> That each of these putative halt deciders recognize and reject all
>>>> and only self-contradictory inputs refutes Rice.
>>>
>>> And you've demonstrated this where, exactly?
>>>
>>> As far as I can tell your H doesn't reject anything. It simply gets
>>> some cases wrong.
>>>
>>
>> The code to reject inputs has not even been fully designed yet.
>
> So why talk about it, then? Until you actually have it you're just
> blowing smoke.
>
>> It is easy to see that the criteria for this already exists.
>
> No. It isn't.
>
>>> Your H(P, P) claims that P(P) doesn't halt, which is wrong.
>>>
>>
>> The input to H(P,P) never halts while H remains in pure simulator mode.
>
> But the definition of halting makes no mention of what happens inside H,
> regardless of whether it remains in 'pure simulator mode'. It makes no
> mention of H at all. It only requires that the *actual* computation P(P)
> reach a final state in a finite amount of time. P(P) meets this definition.
>
> André
>
>>> You claim that you can reject this based on the fact that it doesn't
>>> match which your 'global simulator' concludes.
>>>
>>> But that means that neither the global simulator nor H on their own
>>> are capable of rejecting anything.
>>>
>>
>> So what?
>>
>>> Whatever code is comparing these two values is what is doing the
>>> rejecting. And we can construct from *that* piece of code another
>>> H_Hat which *that* piece of code cannot answer correctly.
>>>
>>> André
>>>
>>
>> I am not going to go down the path of infinitely nested operating
>> systems.
>>
>
>

On 7/28/21 1:06 PM, 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 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.

No, that is NOT true. Remember, to ask the Halting Question, does P(I)
Halt when run or not, P has to be specified, thus if P is H^, then H^
has to be specified, and by the definition of H^, H has to be specified.

Thus, arguments like, 'What should H return?' are improper at this
point. H HAS been specified to get here, so that answer might have been
asked earlier, but its answer has been chosen.

Given that, The question 'Does H^(H^) Halt when run?' has definitive answer.

If H(H^,H^) returns non-halting, then by the rules of constructing H^
then H^(H^) will Halt.

If H*H^,H^) returns halting, then by the rules of constructing H^ then
H^(H^) will fall into an infinite loop.

These are the ONLY possibilities for an H that meets the requirements of
a decider. And in both cases H is wrong.

The other possibilities are H(H^,H^) might get stuck in an infinite
loop, in which case H^(H^) will also be non-halting, or H(H^,H^) might
Halt in some other state and not answer, making H^(H^) also Halt. In
both of these cases H fails to even meet the requirements of a decider.

In both of the first two cases, It is quite easy to build a decider to
get the answer right (since H^ is built on the original H, not this new
decider), so it isn't true that there is no possible answer as in the
liar's paradox.

>
> When we explicitly take into account the self-contradictory nature of
> these two cases things are not as cut-and-dried.
>
> "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
> then we get a contradiction. If it is true that it is not true then that
> makes is not true.

The difference it the statement "This sentence is not true" can not be
assigned a valid truth value.

The question "Does H^(H^) Halt when run (for a SPECIFIC H)?" Has a
specific answer, and this answer is even Provably true if we can prove
what answer H(H^,H^) will give.

Thus, your argument is WRONG, The Halting Question is NOT Paradoxical,
or Pathelogical.

>
> 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
> remains a pure simulator until after it makes its halt status decision
> then its decision that its input never halts is necessarily correct.

Right, but it doesn't prove the statement you want it to, all it proves
is that no H can actually PROVE that H^(H^) is Halting. This does NOT
show that H^(H^) is non-halting. That can be proved, for H(H^,H^) saying
non-halting, but just running or simulating H^(H^), which shows it halts.

You are adding the FALSE premise that all Truth is Provable.

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

P Halting shows that P IS a Halting Computation.

That No H can simulate to this just shows that no H can prove this answer.

Since Truth is NOT always provable, this is a perfectly fine results.

In fact, your argument basically proves this fact, we have a result that
is Provably true with a larger logic, but within the logic of H, the
fact that H^(H^) is Halting is not Provable.

>
>>>>> 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.
>
> 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
> instance of the program that is not an input to H may halt.

But the MACHINE the input represents DOES reach the Halting State, which
is the ACTUAL Question that H is supposed to be answering, and thus we
can PROVE that H^(H^) is Halting and that H(H^,H^) saying non-halting is
WRONG.

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

olcott <NoOne@NoWhere.com> writes:

> On 7/28/2021 10:23 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> I have never been shown guilty of lying.
>> It's hard, in your case, to distinguish between ignorance and deception,
>> but here are some top candidates:
>> "I now have an actual H that decides actual halting for an actual (Ĥ,
>> Ĥ) input pair."
>>
>
> This still seems sufficiently true as elaborated below.
>
>> "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."
>
> This uses a little poetic license in that what I actually had was the
> sufficiently complete C code that correctly decides the impossible
> counter-example inputs.

Whereas the initial claim might be simply wrong, this -- the cover-up --
is a flat-out lie. It is abundantly clear that you were claiming to
have an actual Turing machine. You even said you can provide all the
state transitions:

>> "I provide the exact ... states after the Linz H.q0 and after Ĥ.qx
>> ... showing exactly how the actual Linz H would correctly decide the
>> actual Linz (Ĥ, Ĥ)."

This is meaningless for a scrap of C. And here's what you said a few
days after having what you now claim is C code:

"I am waiting to encode the UTM in C++ so that I can actually execute
H on the input pair: (Ĥ, Ĥ). This should take a week or two. It is not
a universal halt decider, yet it is exactly and precisely the Peter
Linz H and Ĥ, with H actually deciding input pair: (Ĥ, Ĥ)"

This is nonsense unless you wanted the world to believe what you said.
It's patently absurd to claim that you will write something in C++ that
can run your C code "in a week of two". You are simply lying to cover
your mistaken delusion.

>> "I provide the exact ... states after the Linz H.q0 and after Ĥ.qx
>> ... showing exactly how the actual Linz H would correctly decide the
>> actual Linz (Ĥ, Ĥ)."
>
> This idea is elaborated to a much greater extent when H(P,P)...

Still dodging the obvious lie. You were claiming to have an actual
Turing machine. That's why you talked about exact states. You even
named the states. It's a meaningless remark for C code. You were
either lying back, then or you were just deluded and lied later when
covering it up.

And as the cover-up continued, the C vanished. It became an algorithm
and then just a design. But you can clear some of this up. Show the
world what "poetic licence" means you. Post the C code you had more
than two and half years ago that you claimed was "a fully encoded pair
of Turing Machines", "exactly and precisely the Peter Linz H and Ĥ".
Post it now.

>> "I really do have a halting decider."
>>
>> "The non-halting decider that I defined accepts any and all
>> non-halting inputs and rejects any and all halting inputs."
>
> When we apply my design to the halting problem the conventional proofs
> utterly lose their entire basis thus no longer prove that a full halt
> decider cannot exist.

Dodging the subject. You said you /have/ one -- not that one might
exist. Was that true or was it a mistake? I suspect it was just
another lie, but you can correct that perception by telling the world
you were simply mistaken.

>> "Ĥ does not copy its input"
>>
>> Maybe you could point out which of these are simply mistakes and which
>> are deliberate untruths?
>
> Ĥ does copy its input.

Thank you. You admit to a teeny tiny error, though one you argued about
for quite some time and one you never admitted to at the time.

--
Ben.

olcott <NoOne@NoWhere.com> writes:

> Any system that divides all inputs into those having the pathological
> self-reference(Olcott 2004) error and those not having this error does
> refute Rice's theorem no matter how it accomplishes this feat.
>
> I am working on creating the code for this.

Looking back in the record, you claimed to have that in 2012. Did you
lose it? Or maybe you just thought you had such a thing?

--
Ben.

Richard Damon <Richard@Damon-Family.org> writes:

> On 7/28/21 6:56 AM, olcott wrote:

>> Any system that divides all inputs into those having the pathological
>> self-reference(Olcott 2004) error and those not having this error does
>> refute Rice's theorem no matter how it accomplishes this feat.
>>
>> I am working on creating the code for this.
>
> But is that a 'semantic' property or a 'syntactic' property. It seems to
> be a syntactic property, and thus not within realm of Rice's theorem.

PO is unable to state what PSR is in any form that can be used to
resolve this formally, but there are, as you suggest, at least two
reasonable meanings. One is the syntactic property of the input
encoding the "hat" version of the partial decider and the other is an
input that is functionally equivalent to the first case. Rice applies
to the latter but not the former (as you know).

Even if he can't say it, I think he means the latter, or at least he did
9 years ago when this topic was last "hashed out" (i.e. everyone told PO
he was wrong, and PO ignored them and refused to answer any questions).
Oddly he appeared to claim to have such a decider back then. Maybe he
left it on the bus.

--
Ben.

On 7/28/2021 3:38 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/28/2021 10:23 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> I have never been shown guilty of lying.
>>> It's hard, in your case, to distinguish between ignorance and deception,
>>> but here are some top candidates:
>>> "I now have an actual H that decides actual halting for an actual (Ĥ,
>>> Ĥ) input pair."
>>>
>>
>> This still seems sufficiently true as elaborated below.
>>
>>> "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."
>>
>> This uses a little poetic license in that what I actually had was the
>> sufficiently complete C code that correctly decides the impossible
>> counter-example inputs.
>
> Whereas the initial claim might be simply wrong, this -- the cover-up --
> is a flat-out lie. It is abundantly clear that you were claiming to
> have an actual Turing machine. You even said you can provide all the
> state transitions:

That you chop the full context of this statement proves your bias
towards rebuttal over honest dialogue. Bias is a form of deception.

On 7/28/2021 11:01 AM, olcott wrote:
> This uses a little poetic license in that what I actually had was the
> sufficiently complete C code that correctly decides the impossible
> counter-example inputs.
>
> At the time I knew that it was computationally equivalent to Turing
> machines yet was unaware that the concept of: "computationally
> equivalent to Turing machines" was understood to exist.
>
> As it currently stands I apparently did augment the conventional concept
> of Turing equivalence making it broader to encompass all computations
> that can be correctly completed in whatever memory is available.

That what I had was computationally equivalent to what I claimed makes
my claim sufficiently true. The halt deciding aspect of H is the essence
and the heart of it.

--
Copyright 2021 Pete Olcott

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

On 7/28/2021 3:38 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/28/2021 10:23 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> I have never been shown guilty of lying.
>>> It's hard, in your case, to distinguish between ignorance and deception,
>>> but here are some top candidates:
>>> "I now have an actual H that decides actual halting for an actual (Ĥ,
>>> Ĥ) input pair."
>>>
>>
>> This still seems sufficiently true as elaborated below.
>>
>>> "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."
>>
>> This uses a little poetic license in that what I actually had was the
>> sufficiently complete C code that correctly decides the impossible
>> counter-example inputs.
>
> Whereas the initial claim might be simply wrong, this -- the cover-up --
> is a flat-out lie. It is abundantly clear that you were claiming to
> have an actual Turing machine. You even said you can provide all the
> state transitions:
>
>>> "I provide the exact ... states after the Linz H.q0 and after Ĥ.qx
>>> ... showing exactly how the actual Linz H would correctly decide the
>>> actual Linz (Ĥ, Ĥ)."
>
> This is meaningless for a scrap of C. And here's what you said a few
> days after having what you now claim is C code:

Again you dishonestly remove the key context:

This is not C nitwit !

On 7/28/2021 11:01 AM, olcott wrote:
>
> The same applies here: The input to H.qx(Ĥ, Ĥ) cannot possibly
> reach its final state while H.qx remains a pure simulator of
> this input.

Entirely on the basis of the unmodified Linz Ĥ it can be verified that
while the halt decider at H.qx acts as a pure UTM of its input that
H.qx(Ĥ, Ĥ) never halts.

--
Copyright 2021 Pete Olcott

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

On 7/28/2021 4:04 PM, Ben Bacarisse wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> On 7/28/21 6:56 AM, olcott wrote:
>
>>> Any system that divides all inputs into those having the pathological
>>> self-reference(Olcott 2004) error and those not having this error does
>>> refute Rice's theorem no matter how it accomplishes this feat.
>>>
>>> I am working on creating the code for this.
>>
>> But is that a 'semantic' property or a 'syntactic' property. It seems to
>> be a syntactic property, and thus not within realm of Rice's theorem.
>
> PO is unable to state what PSR is in any form that can be used to
> resolve this formally, but there are, as you suggest, at least two
> reasonable meanings. One is the syntactic property of the input
> encoding the "hat" version of the partial decider and the other is an
> input that is functionally equivalent to the first case. Rice applies
> to the latter but not the former (as you know).
>
> Even if he can't say it, I think he means the latter, or at least he did
> 9 years ago when this topic was last "hashed out" (i.e. everyone told PO
> he was wrong, and PO ignored them and refused to answer any questions).
> Oddly he appeared to claim to have such a decider back then. Maybe he
> left it on the bus.
>

Pathological Input to a halt decider is stipulated to mean any input
that was defined to do the opposite of whatever its corresponding halt
decider decides as Sipser describes:

Now we construct a new Turing machine D with H as a subroutine.
This new TM calls H to determine what M does when the input to
M is its own description ⟨M⟩. Once D has determined this information,
it does the opposite. (Sipser:1997:165)

--
Copyright 2021 Pete Olcott

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

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.
>
> When you feed the system self-contradictory input you get an
> inconsistent result that can be used to refute Rice.

Nonsense[1].

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

No answer (of course).

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

No answer.

>> Without the comfort blanket of your huge pile of junk x86 code, I
>> suspect you won't dare say.

As I thought.

[1] I mean that literally. "the system" is a vague, undefined entity.
No input is literally "self-contradictory", but even if we ignore that,
you have never, even after 17 years of trying, been able to define what
such inputs are. And you only get inconsistent results, when the
decider is wrong. Lots of deciders will get that same apparently
"self-contradictory" instance correct. Finally, "can be used to refute
Rice" is laughably vague.

I don't think this is a personal nonsense-density record for you, but it
must be a contender.

--
Ben.

On 7/28/21 2:20 PM, olcott wrote:
> On 7/28/2021 3:38 PM, Ben Bacarisse wrote:
>> The same applies here: The input to H.qx(Ĥ, Ĥ) cannot possibly
>> reach its final state while H.qx remains a pure simulator of
>> this input.
>
> Entirely on the basis of the unmodified Linz Ĥ it can be verified that
> while the halt decider at H.qx acts as a pure UTM of its input that
> H.qx(Ĥ, Ĥ) never halts.
>

If H is a pure UTM, the H will never decide for H^, so it doesn't matter
what H^ does.

If H is NOT a pure UTM, deciding on the H^ built on one is meaningless,
that H need to try to correctly decide on the H^ built from it.

It doesn't matter that H acts like a UTM until it decides, it stil, it
still isn't a pure UTM, and in particular, when H simulates the copy of
H that is part of the machine it is simulating, if the simulating H
presumes that H will NEVER stop simulating, when we KNOW that if it was
allowed to run long enough, it will, then the simulating H has made an
incorrect deduction and is thus using UNSOUND logic, and thus can be, as
it is, WRONG.

Fundamental issue, you reuse terminolgy and use the WRONG definition in
places. FAIL.

You really need to give EACH different version of H an appropriate
variant name, and look at the ^ version of that.

Either Hn or Hu for the H that doesn't abort, and maybe Ha for the H
that does.

From this, your statement becomes:

We can show that Hn(Hn^,Hn^) will never halt and thus Hn^(Hn^) is
non-halting and Ha can answer Ha(Hn^,Hn^) correctly as non-halting.

This makes it clear that Ha hasn't done its job yet, as we are asking
Ha(Ha^,Ha^) and it still says that Ha^(Ha^) is non-halting, even though
we can show by running Ha^(Ha^) we can show that it is Halting, and thus
Ha was wrong about Ha^(Ha^).

The problem is that Ha makes the mistake of assuming that Ha^ and Hn^
behave the same, when they don't. YOU make the same mistake, as you seem
to be blind to the real Truth.

On 7/28/21 2:22 PM, olcott wrote:
> On 7/28/2021 4:04 PM, Ben Bacarisse wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> On 7/28/21 6:56 AM, olcott wrote:
>>
>>>> Any system that divides all inputs into those having the pathological
>>>> self-reference(Olcott 2004) error and those not having this error does
>>>> refute Rice's theorem no matter how it accomplishes this feat.
>>>>
>>>> I am working on creating the code for this.
>>>
>>> But is that a 'semantic' property or a 'syntactic' property. It seems to
>>> be a syntactic property, and thus not within realm of Rice's theorem.
>>
>> PO is unable to state what PSR is in any form that can be used to
>> resolve this formally, but there are, as you suggest, at least two
>> reasonable meanings.  One is the syntactic property of the input
>> encoding the "hat" version of the partial decider and the other is an
>> input that is functionally equivalent to the first case.  Rice applies
>> to the latter but not the former (as you know).
>>
>> Even if he can't say it, I think he means the latter, or at least he did
>> 9 years ago when this topic was last "hashed out" (i.e. everyone told PO
>> he was wrong, and PO ignored them and refused to answer any questions).
>> Oddly he appeared to claim to have such a decider back then.  Maybe he
>> left it on the bus.
>>
>
> Pathological Input to a halt decider is stipulated to mean any input
> that was defined to do the opposite of whatever its corresponding halt
> decider decides as Sipser describes:
>
>    Now we construct a new Turing machine D with H as a subroutine.
>    This new TM calls H to determine what M does when the input to
>    M is its own description ⟨M⟩. Once D has determined this information,
>    it does the opposite.  (Sipser:1997:165)
>
>

Right, but even so defined, the problem still requires the decider to
get this case right. This case HAS a real answer to the actual problem
as stated, it just isn't possible for THIS decider to give that answer.

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.

As you already (generically) agreed:

On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> Truism:
>> Every simulation that would never stop unless Halts() stops
>> it at some point specifies infinite execution.
>
> Any algorithm that implements this truism is, of course, a halting
> decider.

Therefore: when the simulation of the input to Ĥ.qx must be aborted to
prevent the infinite execution of Ĥ applied to ⟨Ĥ⟩ this proves that the
input to Ĥ.qx never halts.

--
Copyright 2021 Pete Olcott

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

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.

Once you define an H that can answer H*H^,H^) then H^(H^) isn't a never
ending cycle.

You confuse these two machine AGAIN.

I think you are just to dumb to understand they are different.

You MUST use the H^ that is derived from the H that you are claiming to
be the possible halt decider, and that H MUST be able to answer H(H^,H^)
which means that H can't be a 'pure simulator', and you must include in
your analysis that it isn't.

To say H is a pure simulator when it isn't is LYING, giving you a FALSE
premise and thus UNSOUND logic.

FAIL.

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.

--
Copyright 2021 Pete Olcott

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

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.

> While the simulating halt decider at Ĥ.qx remains in pure simulator
> mode it specifies a never ending cycle from qx to q0.

The question seems simple to me. Can I help you understand it?

> As you already (generically) agreed:
>
> On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> Truism:
>>> Every simulation that would never stop unless Halts() stops
>>> it at some point specifies infinite execution.
>>
>> Any algorithm that implements this truism is, of course, a halting
>> decider.

Unfortunately I can't answer the question for you.

--
Ben.

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é

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

olcott <NoOne@NoWhere.com> writes:

> On 7/28/2021 3:38 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/28/2021 10:23 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> I have never been shown guilty of lying.
>>>> It's hard, in your case, to distinguish between ignorance and deception,
>>>> but here are some top candidates:
>>>> "I now have an actual H that decides actual halting for an actual (Ĥ,
>>>> Ĥ) input pair."
>>>>
>>>
>>> This still seems sufficiently true as elaborated below.
>>>
>>>> "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."
>>>
>>> This uses a little poetic license in that what I actually had was the
>>> sufficiently complete C code that correctly decides the impossible
>>> counter-example inputs.
>>
>> Whereas the initial claim might be simply wrong, this -- the cover-up --
>> is a flat-out lie. It is abundantly clear that you were claiming to
>> have an actual Turing machine. You even said you can provide all the
>> state transitions:
>>
>>>> "I provide the exact ... states after the Linz H.q0 and after Ĥ.qx
>>>> ... showing exactly how the actual Linz H would correctly decide the
>>>> actual Linz (Ĥ, Ĥ)."
>> This is meaningless for a scrap of C. And here's what you said a few
>> days after having what you now claim is C code:
>
> Again you dishonestly remove the key context:
>
> This is not C nitwit !

You said it was: "what I actually had was ... C code". You can't have
it both ways. Did you have an "actual Turing machines" or "C code"? Do
you realise that you are making it obvious that one of these is a lie?

Clear it up. Post what you had in Dec 2018. You won't, of course
because that will pin-point which claim was the false one. (It might
even be both.)

--
Ben.

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 and instead
proved how we know that Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩) correctly decides that its input
never halts.

Once we know how this is correct every question about it becomes moot.

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.

>> While the simulating halt decider at Ĥ.qx remains in pure simulator
>> mode it specifies a never ending cycle from qx to q0.
>
> The question seems simple to me. Can I help you understand it?
>
>> As you already (generically) agreed:
>>
>> On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> Truism:
>>>> Every simulation that would never stop unless Halts() stops
>>>> it at some point specifies infinite execution.
>>>
>>> Any algorithm that implements this truism is, of course, a halting
>>> decider.
>
> Unfortunately I can't answer the question for you.
>

--
Copyright 2021 Pete Olcott

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

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.

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

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

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

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

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

> When the assertion of a declarative sentence is satisfied this makes the
> sentence true unless the sentence is self-contradictory.
>
> The fact that "This sentence is not true." is not true does not make the
> sentence true because the sentence is self-contradictory.
>
> When a simulating halt decider reports that its input does not halt then
> no instance of the same program ever reaches a final state unless the
> input program specifies self-contradiction.

There are no 'instances of the same program' when talking in terms of
Turing Machines.

André

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

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.

--
Ben.

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.

--
Copyright 2021 Pete Olcott

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

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

I would prefer to move away from division and animosity to achieve an
honest dialogue striving for mutual agreement, are you game?

--
Copyright 2021 Pete Olcott

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

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.

The P of int main(){ P(P); } is one of these inputs therefore H
correctly decides that it never halts.

--
Copyright 2021 Pete Olcott

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

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

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

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