#include <stdint.h>
#include <stdio.h>
typedef int (*ptr)();

int H(ptr x, ptr y)
{ x(y); // direct execution of P(P)
return 1;
}

// Minimal essence of Linz(1990) Ĥ
// and Strachey(1965) P
int P(ptr x)
{ H(x, x);
return 1; // Give P a last instruction at the "c" level
}

int main(void)
{ H(P, P);
}

Computation that halts
a computation is said to halt whenever it enters a final state.
(Linz:1990:234)

PSR set: Combinations of H/P having pathological self-reference
For every possible H of H(P,P) invoked from main() where P(P) calls this
same H(P,P) and H simulates or executes its input and aborts or does not
abort its input P never reaches its last instruction.

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

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

This conclusively proves when the input to H(P,P) never halts and the
same P(P) does halt that this does not form a contradiction.

Halting problem undecidability and infinitely nested simulation (V2)
November 2021 PL Olcott

https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

olcott <NoOne@NoWhere.com> writes:

Subject:
Re: Concise refutation of halting problem proofs V20 [ Ben Bacarisse ]

I would appreciate it if you would not use my name in connection with
your "work". Thank you.

--
Ben.

On 11/19/21 11:43 PM, olcott wrote:
> #include <stdint.h>
> #include <stdio.h>
> typedef int (*ptr)();
>
> int H(ptr x, ptr y)
> {
>   x(y); // direct execution of P(P)
>   return 1;
> }
>
> // Minimal essence of Linz(1990) Ĥ
> // and Strachey(1965) P
> int P(ptr x)
> {
>   H(x, x);
>   return 1; // Give P a last instruction at the "c" level
> }
>
> int main(void)
> {
>   H(P, P);
> }
>
> Computation that halts
> a computation is said to halt whenever it enters a final state.
> (Linz:1990:234)
>
> PSR set: Combinations of H/P having pathological self-reference
> For every possible H of H(P,P) invoked from main() where P(P) calls this
> same H(P,P) and H simulates or executes its input and aborts or does not
> abort its input P never reaches its last instruction.
>
> PSR subset: Because we know that the input to H(P,P) never halts for the
> whole PSR set and a subset of these H/P combinations aborts the
> execution or simulation of its input then we know that for this entire
> subset the input to H(P,P) never halts and H(P,P) halts.
>
> When int main(void) { P(P); } is invoked on H/P elements of the above
> PSR subset, then we have a cases where the input to H(P,P) never halts
> and P(P) halts.
>
> This conclusively proves when the input to H(P,P) never halts and the
> same P(P) does halt that this does not form a contradiction.
>

LIE.

The input to H(P,P) when directly executed runs P(P) which we have many
times showed to halt if H(P,P) returns 0.

Your 'definition' is based on a false definition of halting, saying
Halting is H's simulation not reaching its final state, even if this is
because it aborted it before it reaches the halting state that does
exist in the actual pure exectution of that input.

Thus either H fails to return an answer or its input Halts when it says
non-halting.

Thus ALL H(P,P) fail to give the right answer.

FAIL.

LIE.

You are intentionally misusing an incorrect definition.

>
>
> Halting problem undecidability and infinitely nested simulation (V2)
> November 2021 PL Olcott
>
> https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2
>
>

On 11/20/2021 4:57 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
> Subject:
> Re: Concise refutation of halting problem proofs V20 [ Ben Bacarisse ]
>
> I would appreciate it if you would not use my name in connection with
> your "work". Thank you.
>

I have finally made it clear that when the input to H(P,P) never halts
the fact that (P) halts does not contradict this.

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 11/20/21 10:55 AM, olcott wrote:
> On 11/20/2021 4:57 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>> Subject:
>> Re: Concise refutation of halting problem proofs V20 [ Ben Bacarisse ]
>>
>> I would appreciate it if you would not use my name in connection with
>> your "work".  Thank you.
>>
>
> I have finally made it clear that when the input to H(P,P) never halts
> the fact that (P) halts does not contradict this.
>

Except that by definition the input to H(P,P) IS the representation of
P(P), so you LIE when you say it behaves differently.

FAIL. LIAR.

Or is it idiot because you don't know what you are talking about and it
is just a mistake of ignorance?

olcott <NoOne@NoWhere.com> writes:

> On 11/20/2021 4:57 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>> Subject:
>> Re: Concise refutation of halting problem proofs V20 [ Ben Bacarisse ]
>> I would appreciate it if you would not use my name in connection with
>> your "work". Thank you.
>
> I have finally made it clear that when the input to H(P,P) never halts
> the fact that (P) halts does not contradict this.

I would appreciate it if you would not use my name in connection with
your "work". I can't make you, but I trust you have some sense of
propriety. Thank you.

--
Ben.

On 11/20/2021 10:47 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 11/20/2021 4:57 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>> Subject:
>>> Re: Concise refutation of halting problem proofs V20 [ Ben Bacarisse ]
>>> I would appreciate it if you would not use my name in connection with
>>> your "work". Thank you.
>>
>> I have finally made it clear that when the input to H(P,P) never halts
>> the fact that (P) halts does not contradict this.
>
> I would appreciate it if you would not use my name in connection with
> your "work". I can't make you, but I trust you have some sense of
> propriety. Thank you.
>

Not in this case. You have only unfairly evaluated my work.
Now is your chance for an accurate review.

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 11/20/21 12:48 PM, olcott wrote:
> On 11/20/2021 10:47 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 11/20/2021 4:57 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>> Subject:
>>>> Re: Concise refutation of halting problem proofs V20 [ Ben Bacarisse ]
>>>> I would appreciate it if you would not use my name in connection with
>>>> your "work".  Thank you.
>>>
>>> I have finally made it clear that when the input to H(P,P) never halts
>>> the fact that (P) halts does not contradict this.
>>
>> I would appreciate it if you would not use my name in connection with
>> your "work".  I can't make you, but I trust you have some sense of
>> propriety.  Thank you.
>>
>
> Not in this case. You have only unfairly evaluated my work.
> Now is your chance for an accurate review.
>

No, your 'proof' is still a lie based on using the wrong definitions of
words.

The computation that is the input to H(P,P) WILL halt if H(P,P) returns
the value 0 as long as P is the required computation based on that H.

FAIL.

On 11/20/2021 3:42 PM, Richard Damon wrote:
> On 11/20/21 12:48 PM, olcott wrote:
>> On 11/20/2021 10:47 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 11/20/2021 4:57 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>> Subject:
>>>>> Re: Concise refutation of halting problem proofs V20 [ Ben Bacarisse ]
>>>>> I would appreciate it if you would not use my name in connection with
>>>>> your "work".  Thank you.
>>>>
>>>> I have finally made it clear that when the input to H(P,P) never halts
>>>> the fact that (P) halts does not contradict this.
>>>
>>> I would appreciate it if you would not use my name in connection with
>>> your "work".  I can't make you, but I trust you have some sense of
>>> propriety.  Thank you.
>>>
>>
>> Not in this case. You have only unfairly evaluated my work.
>> Now is your chance for an accurate review.
>>
>
> No, your 'proof' is still a lie based on using the wrong definitions of
> words.
>
> The computation that is the input to H(P,P) WILL halt if H(P,P) returns
> the value 0 as long as P is the required computation based on that H.
>
> FAIL.

Everyone here defines the domain of function H to contain elements that
are only vague ideas.

The domain of function H must actually be a set of elements that each
specify a sequence of configurations.

Function H maps elements of its domain D to {0,1}
Domain D is comprised of elements that specify a sequence of
configurations.
H maps elements E of D to {0,1} on the basis of whether or not E reaches
its final state.

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 11/20/21 4:55 PM, olcott wrote:
> On 11/20/2021 3:42 PM, Richard Damon wrote:
>> On 11/20/21 12:48 PM, olcott wrote:
>>> On 11/20/2021 10:47 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 11/20/2021 4:57 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>> Subject:
>>>>>> Re: Concise refutation of halting problem proofs V20 [ Ben
>>>>>> Bacarisse ]
>>>>>> I would appreciate it if you would not use my name in connection with
>>>>>> your "work".  Thank you.
>>>>>
>>>>> I have finally made it clear that when the input to H(P,P) never halts
>>>>> the fact that (P) halts does not contradict this.
>>>>
>>>> I would appreciate it if you would not use my name in connection with
>>>> your "work".  I can't make you, but I trust you have some sense of
>>>> propriety.  Thank you.
>>>>
>>>
>>> Not in this case. You have only unfairly evaluated my work.
>>> Now is your chance for an accurate review.
>>>
>>
>> No, your 'proof' is still a lie based on using the wrong definitions
>> of words.
>>
>> The computation that is the input to H(P,P) WILL halt if H(P,P)
>> returns the value 0 as long as P is the required computation based on
>> that H.
>>
>> FAIL.
>
> Everyone here defines the domain of function H to contain elements that
> are only vague ideas.
>

LIE.

The Domain of a proper Halt decider is PRECISELY defined.

> The domain of function H must actually be a set of elements that each
> specify a sequence of configurations.

And they do.

>
> Function H maps elements of its domain D to {0,1}
> Domain D is comprised of elements that specify a sequence of
> configurations.
> H maps elements E of D to {0,1} on the basis of whether or not E reaches
> its final state.
>

Except that for the Computation P(P) we KNOW that since H(P,P) returns a
value in finite time, your defined P(P) above WILL ALWAYS return in
finite time and thus is Halting.

What doesn't reach the final state is the aborted internal computation
in H which nobody cares about.

On 11/20/2021 4:06 PM, Richard Damon wrote:
> On 11/20/21 4:55 PM, olcott wrote:
>> On 11/20/2021 3:42 PM, Richard Damon wrote:
>>> On 11/20/21 12:48 PM, olcott wrote:
>>>> On 11/20/2021 10:47 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 11/20/2021 4:57 AM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>> Subject:
>>>>>>> Re: Concise refutation of halting problem proofs V20 [ Ben
>>>>>>> Bacarisse ]
>>>>>>> I would appreciate it if you would not use my name in connection
>>>>>>> with
>>>>>>> your "work".  Thank you.
>>>>>>
>>>>>> I have finally made it clear that when the input to H(P,P) never
>>>>>> halts
>>>>>> the fact that (P) halts does not contradict this.
>>>>>
>>>>> I would appreciate it if you would not use my name in connection with
>>>>> your "work".  I can't make you, but I trust you have some sense of
>>>>> propriety.  Thank you.
>>>>>
>>>>
>>>> Not in this case. You have only unfairly evaluated my work.
>>>> Now is your chance for an accurate review.
>>>>
>>>
>>> No, your 'proof' is still a lie based on using the wrong definitions
>>> of words.
>>>
>>> The computation that is the input to H(P,P) WILL halt if H(P,P)
>>> returns the value 0 as long as P is the required computation based on
>>> that H.
>>>
>>> FAIL.
>>
>> Everyone here defines the domain of function H to contain elements
>> that are only vague ideas.
>>
>
> LIE.
>
>
> The Domain of a proper Halt decider is PRECISELY defined.
>
>> The domain of function H must actually be a set of elements that each
>> specify a sequence of configurations.
>
> And they do.
>
>>
>> Function H maps elements of its domain D to {0,1}
>> Domain D is comprised of elements that specify a sequence of
>> configurations.
>> H maps elements E of D to {0,1} on the basis of whether or not E
>> reaches its final state.
>>
>
> Except that for the Computation P(P)

This is the exact vague idea that cannot possibly exist in the domain of H.

The sequence of configurations specified by the x86 machine language of
P is in the domain of H.

Some vague idea about what P(P) is supposed to do cannot possibly be in
the domain of H.

>> we KNOW that since H(P,P) returns a
> value in finite time, your defined P(P) above WILL ALWAYS return in
> finite time and thus is Halting.
>
> What doesn't reach the final state is the aborted internal computation
> in H which nobody cares about.
>

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 11/20/21 5:12 PM, olcott wrote:
> On 11/20/2021 4:06 PM, Richard Damon wrote:
>> On 11/20/21 4:55 PM, olcott wrote:
>>> On 11/20/2021 3:42 PM, Richard Damon wrote:
>>>> On 11/20/21 12:48 PM, olcott wrote:
>>>>> On 11/20/2021 10:47 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 11/20/2021 4:57 AM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>> Subject:
>>>>>>>> Re: Concise refutation of halting problem proofs V20 [ Ben
>>>>>>>> Bacarisse ]
>>>>>>>> I would appreciate it if you would not use my name in connection
>>>>>>>> with
>>>>>>>> your "work".  Thank you.
>>>>>>>
>>>>>>> I have finally made it clear that when the input to H(P,P) never
>>>>>>> halts
>>>>>>> the fact that (P) halts does not contradict this.
>>>>>>
>>>>>> I would appreciate it if you would not use my name in connection with
>>>>>> your "work".  I can't make you, but I trust you have some sense of
>>>>>> propriety.  Thank you.
>>>>>>
>>>>>
>>>>> Not in this case. You have only unfairly evaluated my work.
>>>>> Now is your chance for an accurate review.
>>>>>
>>>>
>>>> No, your 'proof' is still a lie based on using the wrong definitions
>>>> of words.
>>>>
>>>> The computation that is the input to H(P,P) WILL halt if H(P,P)
>>>> returns the value 0 as long as P is the required computation based
>>>> on that H.
>>>>
>>>> FAIL.
>>>
>>> Everyone here defines the domain of function H to contain elements
>>> that are only vague ideas.
>>>
>>
>> LIE.
>>
>>
>> The Domain of a proper Halt decider is PRECISELY defined.
>>
>>> The domain of function H must actually be a set of elements that each
>>> specify a sequence of configurations.
>>
>> And they do.
>>
>>>
>>> Function H maps elements of its domain D to {0,1}
>>> Domain D is comprised of elements that specify a sequence of
>>> configurations.
>>> H maps elements E of D to {0,1} on the basis of whether or not E
>>> reaches its final state.
>>>
>>
>> Except that for the Computation P(P)
>
> This is the exact vague idea that cannot possibly exist in the domain of H.

This is NOT a 'vague idea', P, which Linz describes as H^, is PRECISELY
defined in terms of H, which you claim to have a definition of.

>
> The sequence of configurations specified by the x86 machine language of
> P is in the domain of H.

And, the x86 machine language of ALL of the execution of P is exactly
what the computation of P is. Note, this includes ALL the x86 machine
language of H and anything that H itself calls.

This is NOT 'vague'

>
> Some vague idea about what P(P) is supposed to do cannot possibly be in
> the domain of H.

If P is vague, then H must be vague too, as Linz defines EXACTLY how to
build H^ (which you are calling P) from ANY H that could exist.

Thus, you calling P 'vague' means either:

1) YOU are LYING,

2) YOU don't understand what Linz has described to do, and thus are not
qualified to say you have come up with a counter for his proof, or

3) The problem is that you H is actually just some 'vague' description
and you have been lying about its existance for all this time.

Which is it?

FAIL

>
>>> we KNOW that since H(P,P) returns a
>> value in finite time, your defined P(P) above WILL ALWAYS return in
>> finite time and thus is Halting.
>>
>> What doesn't reach the final state is the aborted internal computation
>> in H which nobody cares about.
>>
>
>

On 11/20/2021 4:27 PM, Richard Damon wrote:
> On 11/20/21 5:12 PM, olcott wrote:
>> On 11/20/2021 4:06 PM, Richard Damon wrote:
>>> On 11/20/21 4:55 PM, olcott wrote:
>>>> On 11/20/2021 3:42 PM, Richard Damon wrote:
>>>>> On 11/20/21 12:48 PM, olcott wrote:
>>>>>> On 11/20/2021 10:47 AM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 11/20/2021 4:57 AM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>> Subject:
>>>>>>>>> Re: Concise refutation of halting problem proofs V20 [ Ben
>>>>>>>>> Bacarisse ]
>>>>>>>>> I would appreciate it if you would not use my name in
>>>>>>>>> connection with
>>>>>>>>> your "work".  Thank you.
>>>>>>>>
>>>>>>>> I have finally made it clear that when the input to H(P,P) never
>>>>>>>> halts
>>>>>>>> the fact that (P) halts does not contradict this.
>>>>>>>
>>>>>>> I would appreciate it if you would not use my name in connection
>>>>>>> with
>>>>>>> your "work".  I can't make you, but I trust you have some sense of
>>>>>>> propriety.  Thank you.
>>>>>>>
>>>>>>
>>>>>> Not in this case. You have only unfairly evaluated my work.
>>>>>> Now is your chance for an accurate review.
>>>>>>
>>>>>
>>>>> No, your 'proof' is still a lie based on using the wrong
>>>>> definitions of words.
>>>>>
>>>>> The computation that is the input to H(P,P) WILL halt if H(P,P)
>>>>> returns the value 0 as long as P is the required computation based
>>>>> on that H.
>>>>>
>>>>> FAIL.
>>>>
>>>> Everyone here defines the domain of function H to contain elements
>>>> that are only vague ideas.
>>>>
>>>
>>> LIE.
>>>
>>>
>>> The Domain of a proper Halt decider is PRECISELY defined.
>>>
>>>> The domain of function H must actually be a set of elements that
>>>> each specify a sequence of configurations.
>>>
>>> And they do.
>>>
>>>>
>>>> Function H maps elements of its domain D to {0,1}
>>>> Domain D is comprised of elements that specify a sequence of
>>>> configurations.
>>>> H maps elements E of D to {0,1} on the basis of whether or not E
>>>> reaches its final state.
>>>>
>>>
>>> Except that for the Computation P(P)
>>
>> This is the exact vague idea that cannot possibly exist in the domain
>> of H.
>
> This is NOT a 'vague idea', P, which Linz describes as H^, is PRECISELY
> defined in terms of H, which you claim to have a definition of.
>

A specified sequence of configurations can be an element of the domain
of H. Some belief about how P(P) is supposed to behave cannot be such an
element.

>>
>> The sequence of configurations specified by the x86 machine language
>> of P is in the domain of H.
>
> And, the x86 machine language of ALL of the execution of P is exactly
> what the computation of P is. Note, this includes ALL the x86 machine
> language of H and anything that H itself calls.
>
> This is NOT 'vague'
>
>>
>> Some vague idea about what P(P) is supposed to do cannot possibly be
>> in the domain of H.
>
> If P is vague, then H must be vague too, as Linz defines EXACTLY how to
> build H^ (which you are calling P) from ANY H that could exist.
>
> Thus, you calling P 'vague' means either:
>
> 1) YOU are LYING,
>
> 2) YOU don't understand what Linz has described to do, and thus are not
> qualified to say you have come up with a counter for his proof, or
>
> 3) The problem is that you H is actually just some 'vague' description
> and you have been lying about its existance for all this time.
>
>
> Which is it?
>
>
> FAIL
>
>>
>>>> we KNOW that since H(P,P) returns a
>>> value in finite time, your defined P(P) above WILL ALWAYS return in
>>> finite time and thus is Halting.
>>>
>>> What doesn't reach the final state is the aborted internal
>>> computation in H which nobody cares about.
>>>
>>
>>
>

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 11/20/21 5:48 PM, olcott wrote:
> On 11/20/2021 4:27 PM, Richard Damon wrote:
>> On 11/20/21 5:12 PM, olcott wrote:
>>> On 11/20/2021 4:06 PM, Richard Damon wrote:
>>>> On 11/20/21 4:55 PM, olcott wrote:
>>>>> On 11/20/2021 3:42 PM, Richard Damon wrote:
>>>>>> On 11/20/21 12:48 PM, olcott wrote:
>>>>>>> On 11/20/2021 10:47 AM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 11/20/2021 4:57 AM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>> Subject:
>>>>>>>>>> Re: Concise refutation of halting problem proofs V20 [ Ben
>>>>>>>>>> Bacarisse ]
>>>>>>>>>> I would appreciate it if you would not use my name in
>>>>>>>>>> connection with
>>>>>>>>>> your "work".  Thank you.
>>>>>>>>>
>>>>>>>>> I have finally made it clear that when the input to H(P,P)
>>>>>>>>> never halts
>>>>>>>>> the fact that (P) halts does not contradict this.
>>>>>>>>
>>>>>>>> I would appreciate it if you would not use my name in connection
>>>>>>>> with
>>>>>>>> your "work".  I can't make you, but I trust you have some sense of
>>>>>>>> propriety.  Thank you.
>>>>>>>>
>>>>>>>
>>>>>>> Not in this case. You have only unfairly evaluated my work.
>>>>>>> Now is your chance for an accurate review.
>>>>>>>
>>>>>>
>>>>>> No, your 'proof' is still a lie based on using the wrong
>>>>>> definitions of words.
>>>>>>
>>>>>> The computation that is the input to H(P,P) WILL halt if H(P,P)
>>>>>> returns the value 0 as long as P is the required computation based
>>>>>> on that H.
>>>>>>
>>>>>> FAIL.
>>>>>
>>>>> Everyone here defines the domain of function H to contain elements
>>>>> that are only vague ideas.
>>>>>
>>>>
>>>> LIE.
>>>>
>>>>
>>>> The Domain of a proper Halt decider is PRECISELY defined.
>>>>
>>>>> The domain of function H must actually be a set of elements that
>>>>> each specify a sequence of configurations.
>>>>
>>>> And they do.
>>>>
>>>>>
>>>>> Function H maps elements of its domain D to {0,1}
>>>>> Domain D is comprised of elements that specify a sequence of
>>>>> configurations.
>>>>> H maps elements E of D to {0,1} on the basis of whether or not E
>>>>> reaches its final state.
>>>>>
>>>>
>>>> Except that for the Computation P(P)
>>>
>>> This is the exact vague idea that cannot possibly exist in the domain
>>> of H.
>>
>> This is NOT a 'vague idea', P, which Linz describes as H^, is
>> PRECISELY defined in terms of H, which you claim to have a definition of.
>>
>
> A specified sequence of configurations can be an element of the domain
> of H. Some belief about how P(P) is supposed to behave cannot be such an
> element.

And what is 'vague' about Linz's description of how to build H^, which
you call P.

It isn't just 'Some belief', it is PRECISELY defined (but you actually
don't follow it, because your simulator model is broken).

Even with your simulation error, the precise definition of P is
available, and you in fact generate code that does it, you just ignore
the fact that P includes ALL of H and everything it uses.

The ONLY way for H^/P to be vague, is if your H is still some vague
definition, which is what it seems to be at times, after all, you keep
talking about this whole set of things called H.

H is NOT a 'set' of machines, it is a precisely specified machine.

You make H vague to LIE about what it does, as EVERY H gets defeated,
but you mixing Hs you can try to throw up smoke about using different Hs
in different parts of the proof.

On 11/20/2021 5:34 PM, Richard Damon wrote:
>
> On 11/20/21 5:48 PM, olcott wrote:
>> On 11/20/2021 4:27 PM, Richard Damon wrote:
>>> On 11/20/21 5:12 PM, olcott wrote:
>>>> On 11/20/2021 4:06 PM, Richard Damon wrote:
>>>>> On 11/20/21 4:55 PM, olcott wrote:
>>>>>> On 11/20/2021 3:42 PM, Richard Damon wrote:
>>>>>>> On 11/20/21 12:48 PM, olcott wrote:
>>>>>>>> On 11/20/2021 10:47 AM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 11/20/2021 4:57 AM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>> Subject:
>>>>>>>>>>> Re: Concise refutation of halting problem proofs V20 [ Ben
>>>>>>>>>>> Bacarisse ]
>>>>>>>>>>> I would appreciate it if you would not use my name in
>>>>>>>>>>> connection with
>>>>>>>>>>> your "work".  Thank you.
>>>>>>>>>>
>>>>>>>>>> I have finally made it clear that when the input to H(P,P)
>>>>>>>>>> never halts
>>>>>>>>>> the fact that (P) halts does not contradict this.
>>>>>>>>>
>>>>>>>>> I would appreciate it if you would not use my name in
>>>>>>>>> connection with
>>>>>>>>> your "work".  I can't make you, but I trust you have some sense of
>>>>>>>>> propriety.  Thank you.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Not in this case. You have only unfairly evaluated my work.
>>>>>>>> Now is your chance for an accurate review.
>>>>>>>>
>>>>>>>
>>>>>>> No, your 'proof' is still a lie based on using the wrong
>>>>>>> definitions of words.
>>>>>>>
>>>>>>> The computation that is the input to H(P,P) WILL halt if H(P,P)
>>>>>>> returns the value 0 as long as P is the required computation
>>>>>>> based on that H.
>>>>>>>
>>>>>>> FAIL.
>>>>>>
>>>>>> Everyone here defines the domain of function H to contain elements
>>>>>> that are only vague ideas.
>>>>>>
>>>>>
>>>>> LIE.
>>>>>
>>>>>
>>>>> The Domain of a proper Halt decider is PRECISELY defined.
>>>>>
>>>>>> The domain of function H must actually be a set of elements that
>>>>>> each specify a sequence of configurations.
>>>>>
>>>>> And they do.
>>>>>
>>>>>>
>>>>>> Function H maps elements of its domain D to {0,1}
>>>>>> Domain D is comprised of elements that specify a sequence of
>>>>>> configurations.
>>>>>> H maps elements E of D to {0,1} on the basis of whether or not E
>>>>>> reaches its final state.
>>>>>>
>>>>>
>>>>> Except that for the Computation P(P)
>>>>
>>>> This is the exact vague idea that cannot possibly exist in the
>>>> domain of H.
>>>
>>> This is NOT a 'vague idea', P, which Linz describes as H^, is
>>> PRECISELY defined in terms of H, which you claim to have a definition
>>> of.
>>>
>>
>> A specified sequence of configurations can be an element of the domain
>> of H. Some belief about how P(P) is supposed to behave cannot be such
>> an element.
>
> And what is 'vague' about Linz's description of how to build H^, which
> you call P.

On 11/20/2021 5:02 PM, Richard Damon wrote:
> Remember,the FUNDAMENTAL question being asked of a Halt
> Decider is does a given computation, when run independently
> Halt or not when run.

When you try and find a way to translate that into an element of the
domain of function H

YOU FAIL
YOU FAIL
YOU FAIL

halt decider (Olcott 2021)
Function H maps elements of its domain D to {0,1}
Domain D is comprised of elements that specify a sequence of configurations.
H maps elements E of D to {0,1} on the basis of whether or not E reaches
its final state.

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 11/20/21 6:45 PM, olcott wrote:
> On 11/20/2021 5:34 PM, Richard Damon wrote:
>>
>> On 11/20/21 5:48 PM, olcott wrote:
>>> On 11/20/2021 4:27 PM, Richard Damon wrote:
>>>> On 11/20/21 5:12 PM, olcott wrote:
>>>>> On 11/20/2021 4:06 PM, Richard Damon wrote:
>>>>>> On 11/20/21 4:55 PM, olcott wrote:
>>>>>>> On 11/20/2021 3:42 PM, Richard Damon wrote:
>>>>>>>> On 11/20/21 12:48 PM, olcott wrote:
>>>>>>>>> On 11/20/2021 10:47 AM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 11/20/2021 4:57 AM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>> Subject:
>>>>>>>>>>>> Re: Concise refutation of halting problem proofs V20 [ Ben
>>>>>>>>>>>> Bacarisse ]
>>>>>>>>>>>> I would appreciate it if you would not use my name in
>>>>>>>>>>>> connection with
>>>>>>>>>>>> your "work".  Thank you.
>>>>>>>>>>>
>>>>>>>>>>> I have finally made it clear that when the input to H(P,P)
>>>>>>>>>>> never halts
>>>>>>>>>>> the fact that (P) halts does not contradict this.
>>>>>>>>>>
>>>>>>>>>> I would appreciate it if you would not use my name in
>>>>>>>>>> connection with
>>>>>>>>>> your "work".  I can't make you, but I trust you have some
>>>>>>>>>> sense of
>>>>>>>>>> propriety.  Thank you.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Not in this case. You have only unfairly evaluated my work.
>>>>>>>>> Now is your chance for an accurate review.
>>>>>>>>>
>>>>>>>>
>>>>>>>> No, your 'proof' is still a lie based on using the wrong
>>>>>>>> definitions of words.
>>>>>>>>
>>>>>>>> The computation that is the input to H(P,P) WILL halt if H(P,P)
>>>>>>>> returns the value 0 as long as P is the required computation
>>>>>>>> based on that H.
>>>>>>>>
>>>>>>>> FAIL.
>>>>>>>
>>>>>>> Everyone here defines the domain of function H to contain
>>>>>>> elements that are only vague ideas.
>>>>>>>
>>>>>>
>>>>>> LIE.
>>>>>>
>>>>>>
>>>>>> The Domain of a proper Halt decider is PRECISELY defined.
>>>>>>
>>>>>>> The domain of function H must actually be a set of elements that
>>>>>>> each specify a sequence of configurations.
>>>>>>
>>>>>> And they do.
>>>>>>
>>>>>>>
>>>>>>> Function H maps elements of its domain D to {0,1}
>>>>>>> Domain D is comprised of elements that specify a sequence of
>>>>>>> configurations.
>>>>>>> H maps elements E of D to {0,1} on the basis of whether or not E
>>>>>>> reaches its final state.
>>>>>>>
>>>>>>
>>>>>> Except that for the Computation P(P)
>>>>>
>>>>> This is the exact vague idea that cannot possibly exist in the
>>>>> domain of H.
>>>>
>>>> This is NOT a 'vague idea', P, which Linz describes as H^, is
>>>> PRECISELY defined in terms of H, which you claim to have a
>>>> definition of.
>>>>
>>>
>>> A specified sequence of configurations can be an element of the
>>> domain of H. Some belief about how P(P) is supposed to behave cannot
>>> be such an element.
>>
>> And what is 'vague' about Linz's description of how to build H^, which
>> you call P.
>
> On 11/20/2021 5:02 PM, Richard Damon wrote:
> > Remember,the FUNDAMENTAL question being asked of a Halt
> > Decider is does a given computation, when run independently
> > Halt or not when run.
>
> When you try and find a way to translate that into an element of the
> domain of function H
>
> YOU FAIL
> YOU FAIL
> YOU FAIL

LIE.

Is the domain of H not representations of Computations?
If not the H fails to meet the requirement of a Halt Decider and you
have lied about what you are doing.

Is the input to H not the representation of the Computation P(P)?
If not, you have formed the input incorrectly and you have lied about
what you are doing,

If P(P) not a Computation?
If not, why?

Was P not formed by the proper sequence as defined by Linz?
If not, then you have LIED about what you are doing.

If you claim you did, then by the basic properties of Computations, the
only ppossible reason is that H is not a computation, is that the reason?
If that it the reason, then you LIE that H is a candidate to be a
Decider, since only computation are eligable to be deciders.

If there is some other reason, what is it?
THe IS not other grounds for the input to not be in the domain of H.

THUS, YOU LIE and have failed.

>
> halt decider (Olcott 2021)
> Function H maps elements of its domain D to {0,1}
> Domain D is comprised of elements that specify a sequence of
> configurations.
> H maps elements E of D to {0,1} on the basis of whether or not E reaches
> its final state.
>

On 11/20/2021 6:04 PM, Richard Damon wrote:
> On 11/20/21 6:45 PM, olcott wrote:
>> On 11/20/2021 5:34 PM, Richard Damon wrote:
>>>
>>> On 11/20/21 5:48 PM, olcott wrote:
>>>> On 11/20/2021 4:27 PM, Richard Damon wrote:
>>>>> On 11/20/21 5:12 PM, olcott wrote:
>>>>>> On 11/20/2021 4:06 PM, Richard Damon wrote:
>>>>>>> On 11/20/21 4:55 PM, olcott wrote:
>>>>>>>> On 11/20/2021 3:42 PM, Richard Damon wrote:
>>>>>>>>> On 11/20/21 12:48 PM, olcott wrote:
>>>>>>>>>> On 11/20/2021 10:47 AM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 11/20/2021 4:57 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>> Subject:
>>>>>>>>>>>>> Re: Concise refutation of halting problem proofs V20 [ Ben
>>>>>>>>>>>>> Bacarisse ]
>>>>>>>>>>>>> I would appreciate it if you would not use my name in
>>>>>>>>>>>>> connection with
>>>>>>>>>>>>> your "work".  Thank you.
>>>>>>>>>>>>
>>>>>>>>>>>> I have finally made it clear that when the input to H(P,P)
>>>>>>>>>>>> never halts
>>>>>>>>>>>> the fact that (P) halts does not contradict this.
>>>>>>>>>>>
>>>>>>>>>>> I would appreciate it if you would not use my name in
>>>>>>>>>>> connection with
>>>>>>>>>>> your "work".  I can't make you, but I trust you have some
>>>>>>>>>>> sense of
>>>>>>>>>>> propriety.  Thank you.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Not in this case. You have only unfairly evaluated my work.
>>>>>>>>>> Now is your chance for an accurate review.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> No, your 'proof' is still a lie based on using the wrong
>>>>>>>>> definitions of words.
>>>>>>>>>
>>>>>>>>> The computation that is the input to H(P,P) WILL halt if H(P,P)
>>>>>>>>> returns the value 0 as long as P is the required computation
>>>>>>>>> based on that H.
>>>>>>>>>
>>>>>>>>> FAIL.
>>>>>>>>
>>>>>>>> Everyone here defines the domain of function H to contain
>>>>>>>> elements that are only vague ideas.
>>>>>>>>
>>>>>>>
>>>>>>> LIE.
>>>>>>>
>>>>>>>
>>>>>>> The Domain of a proper Halt decider is PRECISELY defined.
>>>>>>>
>>>>>>>> The domain of function H must actually be a set of elements that
>>>>>>>> each specify a sequence of configurations.
>>>>>>>
>>>>>>> And they do.
>>>>>>>
>>>>>>>>
>>>>>>>> Function H maps elements of its domain D to {0,1}
>>>>>>>> Domain D is comprised of elements that specify a sequence of
>>>>>>>> configurations.
>>>>>>>> H maps elements E of D to {0,1} on the basis of whether or not E
>>>>>>>> reaches its final state.
>>>>>>>>
>>>>>>>
>>>>>>> Except that for the Computation P(P)
>>>>>>
>>>>>> This is the exact vague idea that cannot possibly exist in the
>>>>>> domain of H.
>>>>>
>>>>> This is NOT a 'vague idea', P, which Linz describes as H^, is
>>>>> PRECISELY defined in terms of H, which you claim to have a
>>>>> definition of.
>>>>>
>>>>
>>>> A specified sequence of configurations can be an element of the
>>>> domain of H. Some belief about how P(P) is supposed to behave cannot
>>>> be such an element.
>>>
>>> And what is 'vague' about Linz's description of how to build H^,
>>> which you call P.
>>
>> On 11/20/2021 5:02 PM, Richard Damon wrote:
>>  > Remember,the FUNDAMENTAL question being asked of a Halt
>>  > Decider is does a given computation, when run independently
>>  > Halt or not when run.
>>
>> When you try and find a way to translate that into an element of the
>> domain of function H
>>
>> YOU FAIL
>> YOU FAIL
>> YOU FAIL
>
> LIE.
>
> Is the domain of H not representations of Computations?

The domain of H is sets of specified sequences of configurations that
may not be computations. (A computation is defined to halt).

It is the subtle difference between representation and specification
that causes you to get the wrong answer.

There is no mathematically precise way to say this:
> Remember,the FUNDAMENTAL question being asked of a
> Halt Decider is does a given computation, when run
> independently Halt or not when run.

There is no way to put [when run independently]
into any specified sequence of configurations.

Function H only applies to the specified sequence
of configurations not any different sequence that
you only have in your head.

> If not the H fails to meet the requirement of a Halt Decider and you
> have lied about what you are doing.
>
> Is the input to H not the representation of the Computation P(P)?
> If not, you have formed the input incorrectly and you have lied about
> what you are doing,
>
> If P(P) not a Computation?
> If not, why?
>
> Was P not formed by the proper sequence as defined by Linz?
> If not, then you have LIED about what you are doing.
>
> If you claim you did, then by the basic properties of Computations, the
> only ppossible reason is that H is not a computation, is that the reason?
> If that it the reason, then you LIE that H is a candidate to be a
> Decider, since only computation are eligable to be deciders.
>
> If there is some other reason, what is it?
> THe IS not other grounds for the input to not be in the domain of H.
>
> THUS, YOU LIE and have failed.
>
>>
>> halt decider (Olcott 2021)
>> Function H maps elements of its domain D to {0,1}
>> Domain D is comprised of elements that specify a sequence of
>> configurations.
>> H maps elements E of D to {0,1} on the basis of whether or not E
>> reaches its final state.
>>
>

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 11/20/21 7:22 PM, olcott wrote:
> On 11/20/2021 6:04 PM, Richard Damon wrote:
>> On 11/20/21 6:45 PM, olcott wrote:
>>> On 11/20/2021 5:34 PM, Richard Damon wrote:
>>>>
>>>> On 11/20/21 5:48 PM, olcott wrote:
>>>>> On 11/20/2021 4:27 PM, Richard Damon wrote:
>>>>>> On 11/20/21 5:12 PM, olcott wrote:
>>>>>>> On 11/20/2021 4:06 PM, Richard Damon wrote:
>>>>>>>> On 11/20/21 4:55 PM, olcott wrote:
>>>>>>>>> On 11/20/2021 3:42 PM, Richard Damon wrote:
>>>>>>>>>> On 11/20/21 12:48 PM, olcott wrote:
>>>>>>>>>>> On 11/20/2021 10:47 AM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 11/20/2021 4:57 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>> Subject:
>>>>>>>>>>>>>> Re: Concise refutation of halting problem proofs V20 [ Ben
>>>>>>>>>>>>>> Bacarisse ]
>>>>>>>>>>>>>> I would appreciate it if you would not use my name in
>>>>>>>>>>>>>> connection with
>>>>>>>>>>>>>> your "work".  Thank you.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have finally made it clear that when the input to H(P,P)
>>>>>>>>>>>>> never halts
>>>>>>>>>>>>> the fact that (P) halts does not contradict this.
>>>>>>>>>>>>
>>>>>>>>>>>> I would appreciate it if you would not use my name in
>>>>>>>>>>>> connection with
>>>>>>>>>>>> your "work".  I can't make you, but I trust you have some
>>>>>>>>>>>> sense of
>>>>>>>>>>>> propriety.  Thank you.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Not in this case. You have only unfairly evaluated my work.
>>>>>>>>>>> Now is your chance for an accurate review.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> No, your 'proof' is still a lie based on using the wrong
>>>>>>>>>> definitions of words.
>>>>>>>>>>
>>>>>>>>>> The computation that is the input to H(P,P) WILL halt if
>>>>>>>>>> H(P,P) returns the value 0 as long as P is the required
>>>>>>>>>> computation based on that H.
>>>>>>>>>>
>>>>>>>>>> FAIL.
>>>>>>>>>
>>>>>>>>> Everyone here defines the domain of function H to contain
>>>>>>>>> elements that are only vague ideas.
>>>>>>>>>
>>>>>>>>
>>>>>>>> LIE.
>>>>>>>>
>>>>>>>>
>>>>>>>> The Domain of a proper Halt decider is PRECISELY defined.
>>>>>>>>
>>>>>>>>> The domain of function H must actually be a set of elements
>>>>>>>>> that each specify a sequence of configurations.
>>>>>>>>
>>>>>>>> And they do.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Function H maps elements of its domain D to {0,1}
>>>>>>>>> Domain D is comprised of elements that specify a sequence of
>>>>>>>>> configurations.
>>>>>>>>> H maps elements E of D to {0,1} on the basis of whether or not
>>>>>>>>> E reaches its final state.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Except that for the Computation P(P)
>>>>>>>
>>>>>>> This is the exact vague idea that cannot possibly exist in the
>>>>>>> domain of H.
>>>>>>
>>>>>> This is NOT a 'vague idea', P, which Linz describes as H^, is
>>>>>> PRECISELY defined in terms of H, which you claim to have a
>>>>>> definition of.
>>>>>>
>>>>>
>>>>> A specified sequence of configurations can be an element of the
>>>>> domain of H. Some belief about how P(P) is supposed to behave
>>>>> cannot be such an element.
>>>>
>>>> And what is 'vague' about Linz's description of how to build H^,
>>>> which you call P.
>>>
>>> On 11/20/2021 5:02 PM, Richard Damon wrote:
>>>  > Remember,the FUNDAMENTAL question being asked of a Halt
>>>  > Decider is does a given computation, when run independently
>>>  > Halt or not when run.
>>>
>>> When you try and find a way to translate that into an element of the
>>> domain of function H
>>>
>>> YOU FAIL
>>> YOU FAIL
>>> YOU FAIL
>>
>> LIE.
>>
>> Is the domain of H not representations of Computations?
>
> The domain of H is sets of specified sequences of configurations that
> may not be computations. (A computation is defined to halt).
>
> It is the subtle difference between representation and specification
> that causes you to get the wrong answer.
>
> There is no mathematically precise way to say this:
> > Remember,the FUNDAMENTAL question being asked of a
> > Halt Decider is does a given computation, when run
> > independently Halt or not when run.
>
> There is no way to put [when run independently]
> into any specified sequence of configurations.

Why not?

I guess you just don't understand computations.

If your H can't handle the actual computation P, then it just fails to
be the example needed.

>
> Function H only applies to the specified sequence
> of configurations not any different sequence that
> you only have in your head.
>

If H can not accept the computation built by the Linz H^ transformation,
then it can not be a counter example for the Linz Proof.

PERIOD.

I guess you put your foot into your mouth with that one.

On 11/20/2021 6:31 PM, Richard Damon wrote:
> On 11/20/21 7:22 PM, olcott wrote:
>> On 11/20/2021 6:04 PM, Richard Damon wrote:
>>> On 11/20/21 6:45 PM, olcott wrote:
>>>> On 11/20/2021 5:34 PM, Richard Damon wrote:
>>>>>
>>>>> On 11/20/21 5:48 PM, olcott wrote:
>>>>>> On 11/20/2021 4:27 PM, Richard Damon wrote:
>>>>>>> On 11/20/21 5:12 PM, olcott wrote:
>>>>>>>> On 11/20/2021 4:06 PM, Richard Damon wrote:
>>>>>>>>> On 11/20/21 4:55 PM, olcott wrote:
>>>>>>>>>> On 11/20/2021 3:42 PM, Richard Damon wrote:
>>>>>>>>>>> On 11/20/21 12:48 PM, olcott wrote:
>>>>>>>>>>>> On 11/20/2021 10:47 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 11/20/2021 4:57 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>> Subject:
>>>>>>>>>>>>>>> Re: Concise refutation of halting problem proofs V20 [
>>>>>>>>>>>>>>> Ben Bacarisse ]
>>>>>>>>>>>>>>> I would appreciate it if you would not use my name in
>>>>>>>>>>>>>>> connection with
>>>>>>>>>>>>>>> your "work".  Thank you.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have finally made it clear that when the input to H(P,P)
>>>>>>>>>>>>>> never halts
>>>>>>>>>>>>>> the fact that (P) halts does not contradict this.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I would appreciate it if you would not use my name in
>>>>>>>>>>>>> connection with
>>>>>>>>>>>>> your "work".  I can't make you, but I trust you have some
>>>>>>>>>>>>> sense of
>>>>>>>>>>>>> propriety.  Thank you.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Not in this case. You have only unfairly evaluated my work.
>>>>>>>>>>>> Now is your chance for an accurate review.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> No, your 'proof' is still a lie based on using the wrong
>>>>>>>>>>> definitions of words.
>>>>>>>>>>>
>>>>>>>>>>> The computation that is the input to H(P,P) WILL halt if
>>>>>>>>>>> H(P,P) returns the value 0 as long as P is the required
>>>>>>>>>>> computation based on that H.
>>>>>>>>>>>
>>>>>>>>>>> FAIL.
>>>>>>>>>>
>>>>>>>>>> Everyone here defines the domain of function H to contain
>>>>>>>>>> elements that are only vague ideas.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> LIE.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The Domain of a proper Halt decider is PRECISELY defined.
>>>>>>>>>
>>>>>>>>>> The domain of function H must actually be a set of elements
>>>>>>>>>> that each specify a sequence of configurations.
>>>>>>>>>
>>>>>>>>> And they do.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Function H maps elements of its domain D to {0,1}
>>>>>>>>>> Domain D is comprised of elements that specify a sequence of
>>>>>>>>>> configurations.
>>>>>>>>>> H maps elements E of D to {0,1} on the basis of whether or not
>>>>>>>>>> E reaches its final state.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Except that for the Computation P(P)
>>>>>>>>
>>>>>>>> This is the exact vague idea that cannot possibly exist in the
>>>>>>>> domain of H.
>>>>>>>
>>>>>>> This is NOT a 'vague idea', P, which Linz describes as H^, is
>>>>>>> PRECISELY defined in terms of H, which you claim to have a
>>>>>>> definition of.
>>>>>>>
>>>>>>
>>>>>> A specified sequence of configurations can be an element of the
>>>>>> domain of H. Some belief about how P(P) is supposed to behave
>>>>>> cannot be such an element.
>>>>>
>>>>> And what is 'vague' about Linz's description of how to build H^,
>>>>> which you call P.
>>>>
>>>> On 11/20/2021 5:02 PM, Richard Damon wrote:
>>>>  > Remember,the FUNDAMENTAL question being asked of a Halt
>>>>  > Decider is does a given computation, when run independently
>>>>  > Halt or not when run.
>>>>
>>>> When you try and find a way to translate that into an element of the
>>>> domain of function H
>>>>
>>>> YOU FAIL
>>>> YOU FAIL
>>>> YOU FAIL
>>>
>>> LIE.
>>>
>>> Is the domain of H not representations of Computations?
>>
>> The domain of H is sets of specified sequences of configurations that
>> may not be computations. (A computation is defined to halt).
>>
>> It is the subtle difference between representation and specification
>> that causes you to get the wrong answer.
>>
>> There is no mathematically precise way to say this:
>>  > Remember,the FUNDAMENTAL question being asked of a
>>  > Halt Decider is does a given computation, when run
>>  > independently Halt or not when run.
>>
>> There is no way to put [when run independently]
>> into any specified sequence of configurations.
>
> Why not?
>

How do you tell a mathematical function that it is not allowed to base
its halt status decision on the sequence of configurations specified by
(P, I) and instead must base its halt status decision on P(I) [when run
independently] ???

> I guess you just don't understand computations.
>
> If your H can't handle the actual computation P, then it just fails to
> be the example needed.
>
>>
>> Function H only applies to the specified sequence
>> of configurations not any different sequence that
>> you only have in your head.
>>
>
> If H can not accept the computation built by the Linz H^ transformation,
> then it can not be a counter example for the Linz Proof.
>
> PERIOD.
>
> I guess you put your foot into your mouth with that one.

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 11/20/2021 6:31 PM, Richard Damon wrote:
> On 11/20/21 7:22 PM, olcott wrote:
>> On 11/20/2021 6:04 PM, Richard Damon wrote:
>>> On 11/20/21 6:45 PM, olcott wrote:
>>>> On 11/20/2021 5:34 PM, Richard Damon wrote:
>>>>>
>>>>> On 11/20/21 5:48 PM, olcott wrote:
>>>>>> On 11/20/2021 4:27 PM, Richard Damon wrote:
>>>>>>> On 11/20/21 5:12 PM, olcott wrote:
>>>>>>>> On 11/20/2021 4:06 PM, Richard Damon wrote:
>>>>>>>>> On 11/20/21 4:55 PM, olcott wrote:
>>>>>>>>>> On 11/20/2021 3:42 PM, Richard Damon wrote:
>>>>>>>>>>> On 11/20/21 12:48 PM, olcott wrote:
>>>>>>>>>>>> On 11/20/2021 10:47 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 11/20/2021 4:57 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>> Subject:
>>>>>>>>>>>>>>> Re: Concise refutation of halting problem proofs V20 [
>>>>>>>>>>>>>>> Ben Bacarisse ]
>>>>>>>>>>>>>>> I would appreciate it if you would not use my name in
>>>>>>>>>>>>>>> connection with
>>>>>>>>>>>>>>> your "work".  Thank you.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have finally made it clear that when the input to H(P,P)
>>>>>>>>>>>>>> never halts
>>>>>>>>>>>>>> the fact that (P) halts does not contradict this.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I would appreciate it if you would not use my name in
>>>>>>>>>>>>> connection with
>>>>>>>>>>>>> your "work".  I can't make you, but I trust you have some
>>>>>>>>>>>>> sense of
>>>>>>>>>>>>> propriety.  Thank you.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Not in this case. You have only unfairly evaluated my work.
>>>>>>>>>>>> Now is your chance for an accurate review.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> No, your 'proof' is still a lie based on using the wrong
>>>>>>>>>>> definitions of words.
>>>>>>>>>>>
>>>>>>>>>>> The computation that is the input to H(P,P) WILL halt if
>>>>>>>>>>> H(P,P) returns the value 0 as long as P is the required
>>>>>>>>>>> computation based on that H.
>>>>>>>>>>>
>>>>>>>>>>> FAIL.
>>>>>>>>>>
>>>>>>>>>> Everyone here defines the domain of function H to contain
>>>>>>>>>> elements that are only vague ideas.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> LIE.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The Domain of a proper Halt decider is PRECISELY defined.
>>>>>>>>>
>>>>>>>>>> The domain of function H must actually be a set of elements
>>>>>>>>>> that each specify a sequence of configurations.
>>>>>>>>>
>>>>>>>>> And they do.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Function H maps elements of its domain D to {0,1}
>>>>>>>>>> Domain D is comprised of elements that specify a sequence of
>>>>>>>>>> configurations.
>>>>>>>>>> H maps elements E of D to {0,1} on the basis of whether or not
>>>>>>>>>> E reaches its final state.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Except that for the Computation P(P)
>>>>>>>>
>>>>>>>> This is the exact vague idea that cannot possibly exist in the
>>>>>>>> domain of H.
>>>>>>>
>>>>>>> This is NOT a 'vague idea', P, which Linz describes as H^, is
>>>>>>> PRECISELY defined in terms of H, which you claim to have a
>>>>>>> definition of.
>>>>>>>
>>>>>>
>>>>>> A specified sequence of configurations can be an element of the
>>>>>> domain of H. Some belief about how P(P) is supposed to behave
>>>>>> cannot be such an element.
>>>>>
>>>>> And what is 'vague' about Linz's description of how to build H^,
>>>>> which you call P.
>>>>
>>>> On 11/20/2021 5:02 PM, Richard Damon wrote:
>>>>  > Remember,the FUNDAMENTAL question being asked of a Halt
>>>>  > Decider is does a given computation, when run independently
>>>>  > Halt or not when run.
>>>>
>>>> When you try and find a way to translate that into an element of the
>>>> domain of function H
>>>>
>>>> YOU FAIL
>>>> YOU FAIL
>>>> YOU FAIL
>>>
>>> LIE.
>>>
>>> Is the domain of H not representations of Computations?
>>
>> The domain of H is sets of specified sequences of configurations that
>> may not be computations. (A computation is defined to halt).
>>
>> It is the subtle difference between representation and specification
>> that causes you to get the wrong answer.
>>
>> There is no mathematically precise way to say this:
>>  > Remember,the FUNDAMENTAL question being asked of a
>>  > Halt Decider is does a given computation, when run
>>  > independently Halt or not when run.
>>
>> There is no way to put [when run independently]
>> into any specified sequence of configurations.
>
> Why not?
>

How do you tell a mathematical function that it is not allowed to base
its halt status decision on the sequence of configurations specified by
(P, I) and instead must base its halt status decision on P(I) [when run
independently] ???

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 2021-11-20 15:12, olcott wrote:
> On 11/20/2021 4:06 PM, Richard Damon wrote:
>> On 11/20/21 4:55 PM, olcott wrote:
>>> On 11/20/2021 3:42 PM, Richard Damon wrote:
>>>> On 11/20/21 12:48 PM, olcott wrote:
>>>>> On 11/20/2021 10:47 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 11/20/2021 4:57 AM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>> Subject:
>>>>>>>> Re: Concise refutation of halting problem proofs V20 [ Ben
>>>>>>>> Bacarisse ]
>>>>>>>> I would appreciate it if you would not use my name in connection
>>>>>>>> with
>>>>>>>> your "work".  Thank you.
>>>>>>>
>>>>>>> I have finally made it clear that when the input to H(P,P) never
>>>>>>> halts
>>>>>>> the fact that (P) halts does not contradict this.
>>>>>>
>>>>>> I would appreciate it if you would not use my name in connection with
>>>>>> your "work".  I can't make you, but I trust you have some sense of
>>>>>> propriety.  Thank you.
>>>>>>
>>>>>
>>>>> Not in this case. You have only unfairly evaluated my work.
>>>>> Now is your chance for an accurate review.
>>>>>
>>>>
>>>> No, your 'proof' is still a lie based on using the wrong definitions
>>>> of words.
>>>>
>>>> The computation that is the input to H(P,P) WILL halt if H(P,P)
>>>> returns the value 0 as long as P is the required computation based
>>>> on that H.
>>>>
>>>> FAIL.
>>>
>>> Everyone here defines the domain of function H to contain elements
>>> that are only vague ideas.
>>>
>>
>> LIE.
>>
>>
>> The Domain of a proper Halt decider is PRECISELY defined.
>>
>>> The domain of function H must actually be a set of elements that each
>>> specify a sequence of configurations.
>>
>> And they do.
>>
>>>
>>> Function H maps elements of its domain D to {0,1}
>>> Domain D is comprised of elements that specify a sequence of
>>> configurations.
>>> H maps elements E of D to {0,1} on the basis of whether or not E
>>> reaches its final state.
>>>
>>
>> Except that for the Computation P(P)
>
> This is the exact vague idea that cannot possibly exist in the domain of H.
>
> The sequence of configurations specified by the x86 machine language of
> P is in the domain of H.
>
> Some vague idea about what P(P) is supposed to do cannot possibly be in
> the domain of H.

Which 'vague idea'?

A halt decider doesn't decide what P(P) is "supposed" to do. It decides
what it actually *does* do when run directly from main. There's nothing
remotely vague about that.

I think you are confusing the term 'domain' with the term 'scope'. When
you call P(P) from within H it is within the scope of H. when you
execute it directly from main it is not within the scope of H. Scope and
domain are entirely different things.

And a halt decider describes the behaviour of independent computations,
not of functions called from within the scope of the decider.

André

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

On 11/20/2021 6:47 PM, André G. Isaak wrote:
> On 2021-11-20 15:12, olcott wrote:
>> On 11/20/2021 4:06 PM, Richard Damon wrote:
>>> On 11/20/21 4:55 PM, olcott wrote:
>>>> On 11/20/2021 3:42 PM, Richard Damon wrote:
>>>>> On 11/20/21 12:48 PM, olcott wrote:
>>>>>> On 11/20/2021 10:47 AM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 11/20/2021 4:57 AM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>> Subject:
>>>>>>>>> Re: Concise refutation of halting problem proofs V20 [ Ben
>>>>>>>>> Bacarisse ]
>>>>>>>>> I would appreciate it if you would not use my name in
>>>>>>>>> connection with
>>>>>>>>> your "work".  Thank you.
>>>>>>>>
>>>>>>>> I have finally made it clear that when the input to H(P,P) never
>>>>>>>> halts
>>>>>>>> the fact that (P) halts does not contradict this.
>>>>>>>
>>>>>>> I would appreciate it if you would not use my name in connection
>>>>>>> with
>>>>>>> your "work".  I can't make you, but I trust you have some sense of
>>>>>>> propriety.  Thank you.
>>>>>>>
>>>>>>
>>>>>> Not in this case. You have only unfairly evaluated my work.
>>>>>> Now is your chance for an accurate review.
>>>>>>
>>>>>
>>>>> No, your 'proof' is still a lie based on using the wrong
>>>>> definitions of words.
>>>>>
>>>>> The computation that is the input to H(P,P) WILL halt if H(P,P)
>>>>> returns the value 0 as long as P is the required computation based
>>>>> on that H.
>>>>>
>>>>> FAIL.
>>>>
>>>> Everyone here defines the domain of function H to contain elements
>>>> that are only vague ideas.
>>>>
>>>
>>> LIE.
>>>
>>>
>>> The Domain of a proper Halt decider is PRECISELY defined.
>>>
>>>> The domain of function H must actually be a set of elements that
>>>> each specify a sequence of configurations.
>>>
>>> And they do.
>>>
>>>>
>>>> Function H maps elements of its domain D to {0,1}
>>>> Domain D is comprised of elements that specify a sequence of
>>>> configurations.
>>>> H maps elements E of D to {0,1} on the basis of whether or not E
>>>> reaches its final state.
>>>>
>>>
>>> Except that for the Computation P(P)
>>
>> This is the exact vague idea that cannot possibly exist in the domain
>> of H.
>>
>> The sequence of configurations specified by the x86 machine language
>> of P is in the domain of H.
>>
>> Some vague idea about what P(P) is supposed to do cannot possibly be
>> in the domain of H.
>
> Which 'vague idea'?
>
> A halt decider doesn't decide what P(P) is "supposed" to do. It decides
> what it actually *does* do when run directly from main. There's nothing
> remotely vague about that.
>
> I think you are confusing the term 'domain' with the term 'scope'. When
> you call P(P) from within H it is within the scope of H. when you
> execute it directly from main it is not within the scope of H. Scope and
> domain are entirely different things.
>
> And a halt decider describes the behaviour of independent computations,
> not of functions called from within the scope of the decider.
>
> André
>

How do you tell a mathematical function that it is not allowed to base
its halt status decision on the sequence of configurations specified by
(P, I) and instead must base its halt status decision on P(I) [when run
independently] ???

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 11/20/21 7:44 PM, olcott wrote:
>>
>
> How do you tell a mathematical function that it is not allowed to base
> its halt status decision on the sequence of configurations specified by
> (P, I) and instead must base its halt status decision on P(I) [when run
> independently] ???
>

That is a silly question and shows you don't know what you are talking
about.

H is a specific algorigthm, chosen by its designer to try to solve a
problem.

The programmer tells H what steps it is supposed to do, and then the
machine that is programmed with H runs those steps with the input it is
given.

"Get the right answer" is NOT an algorithm.

H of course has to base its answer on the stuff it does on its input,
but the RIGHT answer is based on the specifications the programmer was
trying to meet.

After it does its stuff, then a PERSON can look at what H said, and look
at what the computation the input was a representation of will do when
it is computed, and see if H was right.

Since if H(P,P) answers 0, we can easily see (and you even admit) that
when we run P(P) as an independent program it will halt in finite time
(even just slightly longer than it took H to answer wrongly). Thus it is
easy to see that H was WRONG.

Maybe you just don't understand what it means to write a program to some
specifications.

On 11/20/2021 7:35 PM, Richard Damon wrote:
> On 11/20/21 7:44 PM, olcott wrote:
>>>
>>
>> How do you tell a mathematical function that it is not allowed to base
>> its halt status decision on the sequence of configurations specified
>> by (P, I) and instead must base its halt status decision on P(I) [when
>> run independently] ???
>>
>
> That is a silly question and shows you don't know what you are talking
> about.
>
For mathematical function H:
specified sequences of configurations reach their final state or not

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 11/20/21 8:38 PM, olcott wrote:
> On 11/20/2021 7:35 PM, Richard Damon wrote:
>> On 11/20/21 7:44 PM, olcott wrote:
>>>>
>>>
>>> How do you tell a mathematical function that it is not allowed to
>>> base its halt status decision on the sequence of configurations
>>> specified by (P, I) and instead must base its halt status decision on
>>> P(I) [when run independently] ???
>>>
>>
>> That is a silly question and shows you don't know what you are talking
>> about.
>>
> For mathematical function H:
> specified sequences of configurations reach their final state or not
>

So you are just talking POOP and lying about you working on the Halting
Problem.