On 8/22/2021 2:41 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/22/2021 1:56 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> The executed instances of H(P,P) are distinctly different
>>>> computations...
>>> More deflection. Here's why you are wrong:
>>> a. The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation of your Ĥ applied to ⟨Ĥ⟩.
>>> b. Your Ĥ applied to ⟨Ĥ⟩ halts.
>>> c. Your H rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩ when it should accept it.
>>> Which of these facts do you deny?
>>
>> So in other words you are saying that a computation that can be and is
>> aborted is exactly the same as a computation that cannot be and is not
>> aborted?
>
> No, I am not saying that. Which of a, b or c do you deny?
>

I already answered that, you have to pay attention to what I say BEFORE
you try to form a rebuttal.

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn

The execution of Ĥ is computationally distinct from the simulation of
⟨Ĥ1⟩ ⟨Ĥ2⟩ by the simulating halt decider at Ĥ.qx so the fact that Ĥ.qx
transitions to its final state of Ĥ.qn does not contradict the fact that
Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ correctly decides that its input never halts.

THIS SEEMS BEYOND YOUR CAPACITY TO COMPREHEND:
The executed instances of Ĥ are not under the dominion of a simulating
halt decider that can abort them before they get started. This
conclusively proves that they can have different behavior without
forming any contradiction.

Deceptive double-talk may fool the the gullible ignorant ones especially
if you dishonestly make sure to erase the context that you are
responding to.

--
Copyright 2021 Pete Olcott

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

On 8/22/2021 2:46 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
> (anything to avoid addressing the incontrovertible facts)
>
>> On 8/22/2021 2:00 PM, Ben Bacarisse wrote:
>
>>>>> a. The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation of your Ĥ applied to ⟨Ĥ⟩.
>>>>> b. Your Ĥ applied to ⟨Ĥ⟩ halts.
>>>>> c. Your H rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩ when it should accept it.
>>>
>>> I take it you agree with a, b and c since you make no comment about
>>> them. If you do not agree, you need to say which ones you disagree
>>> with.
>
> You have not said which of a, b or c you deny. I don't want to put
> words in your mouth (what sort of person would do that, eh?) but I will
> have to assume you agree with them all if you don't say.
>

As I have already explained in complete detail your simplistic analysis
conflates together two distinctly different computations:
(1) Executed Ĥ applied to ⟨Ĥ⟩ // can't be aborted

(2) Simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ by a simulating halt decider
// can be and is aborted.

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn

The execution of Ĥ is computationally distinct from the simulation of
⟨Ĥ1⟩ ⟨Ĥ2⟩ by the simulating halt decider at Ĥ.qx so the fact that Ĥ.qx
transitions to its final state of Ĥ.qn does not contradict the fact that
Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ correctly decides that its input never halts.

THIS SEEMS BEYOND YOUR CAPACITY TO COMPREHEND:
The executed instances of Ĥ are not under the dominion of a simulating
halt decider that can abort them before they get started. This
conclusively proves that they can have different behavior without
forming any contradiction.

--
Copyright 2021 Pete Olcott

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

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/19/2021 8:14 AM, Ben Bacarisse wrote:

>>> Your mission, should you chose to accept it, is to write a return
>>> decider B with this prototype
>>>
>>> typedef uintptr_t data;
>>> typedef void (*function)(data);
>>> extern _Bool B(function, data);
>>>
>>> such that B(f, d) returns true if and only if a call of f from main with
>>> argument d returns to main. The two arguments, f and d, are said to
>>> represenet the call expression f(d).
>>>
>>> If, rather than just thinking you can do this, you have actual C code,
>>> you should provide either source or a compiled translation unit that can
>>> be linked with this one:
>>>
>>> #include <stdint.h>
>>> #include <stdio.h>
>>>
>>> typedef uintptr_t data;
>>> typedef void (*function)(data);
>>>
>>> extern _Bool B(function, data);
>>> void B_hat(data x) { if (B((function)x, x)) while (1); }
>>> int main(void)
>>> {
>>> printf("%d\n", B(B_hat, (data)B_hat));
>>> fflush(stdout);
>>> B_hat((data)B_hat);
>>> puts("returned");
>>> }
>>>
>>> The output should be either
>>>
>>> 1
>>> returned
>>>
>>> or
>>>
>>> 0
>>>
>>> with no further output. Of course you could always just agree that no
>>> such function B can be written.

>> #include <stdint.h>
>> #include <stdio.h>
>>
>> typedef uintptr_t data;
>> typedef void (*function)(data);
>>
>> extern _Bool B(function, data);
>>
>> void B_hat(data x) { if (H((u32)x, (u32)x)) while (1); }
>>
>> int main2()
>> {
>> OutputHex(H((u32)B_hat, (u32)B_hat));
>> B_hat((u32)B_hat);
>> OutputString("returned");
>> }
>
> This shows no function B. And it's not even valid C. How does it help
> meet the challenge?

>> machine stack stack machine assembly
>> address address data code language
>> ======== ======== ======== ========= =============
>> ...[00000f6c][00101c0a][00000000] 55 push ebp

Long trace including output:

>> 0
.... and ...
>> returned

> B does not do what is required of it to meet my specification. I am
> sure it meets yours but that was not the challenge.

To wrap up this sub-thread, let's just say that you currently can't see
how to meet my specification.

--
Ben.

On 8/22/2021 3:09 PM, Ben Bacarisse wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/19/2021 8:14 AM, Ben Bacarisse wrote:
>
>>>> Your mission, should you chose to accept it, is to write a return
>>>> decider B with this prototype
>>>>
>>>> typedef uintptr_t data;
>>>> typedef void (*function)(data);
>>>> extern _Bool B(function, data);
>>>>
>>>> such that B(f, d) returns true if and only if a call of f from main with
>>>> argument d returns to main. The two arguments, f and d, are said to
>>>> represenet the call expression f(d).
>>>>
>>>> If, rather than just thinking you can do this, you have actual C code,
>>>> you should provide either source or a compiled translation unit that can
>>>> be linked with this one:
>>>>
>>>> #include <stdint.h>
>>>> #include <stdio.h>
>>>>
>>>> typedef uintptr_t data;
>>>> typedef void (*function)(data);
>>>>
>>>> extern _Bool B(function, data);
>>>> void B_hat(data x) { if (B((function)x, x)) while (1); }
>>>> int main(void)
>>>> {
>>>> printf("%d\n", B(B_hat, (data)B_hat));
>>>> fflush(stdout);
>>>> B_hat((data)B_hat);
>>>> puts("returned");
>>>> }
>>>>
>>>> The output should be either
>>>>
>>>> 1
>>>> returned
>>>>
>>>> or
>>>>
>>>> 0
>>>>
>>>> with no further output. Of course you could always just agree that no
>>>> such function B can be written.
>
>>> #include <stdint.h>
>>> #include <stdio.h>
>>>
>>> typedef uintptr_t data;
>>> typedef void (*function)(data);
>>>
>>> extern _Bool B(function, data);
>>>
>>> void B_hat(data x) { if (H((u32)x, (u32)x)) while (1); }
>>>
>>> int main2()
>>> {
>>> OutputHex(H((u32)B_hat, (u32)B_hat));
>>> B_hat((u32)B_hat);
>>> OutputString("returned");
>>> }
>>
>> This shows no function B. And it's not even valid C. How does it help
>> meet the challenge?
>
>>> machine stack stack machine assembly
>>> address address data code language
>>> ======== ======== ======== ========= =============
>>> ...[00000f6c][00101c0a][00000000] 55 push ebp
>
> Long trace including output:
>
>>> 0
> ... and ...
>>> returned
>
>> B does not do what is required of it to meet my specification. I am
>> sure it meets yours but that was not the challenge.
>
> To wrap up this sub-thread, let's just say that you currently can't see
> how to meet my specification.
>

Let's just say that it is not cost effective for me to untangle any more
convoluted paraphrase of the exact same things that I have already been
saying without a specific high level overview of material differences
that seem to be non-existent.

--
Copyright 2021 Pete Olcott

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

On 8/22/21 3:59 PM, olcott wrote:
> On 8/22/2021 2:41 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/22/2021 1:56 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> The executed instances of H(P,P) are distinctly different
>>>>> computations...
>>>> More deflection.  Here's why you are wrong:
>>>> a. The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation of your Ĥ applied to ⟨Ĥ⟩.
>>>> b. Your Ĥ applied to ⟨Ĥ⟩ halts.
>>>> c. Your H rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩ when it should accept it.
>>>> Which of these facts do you deny?
>>>
>>> So in other words you are saying that a computation that can be and is
>>> aborted is exactly the same as a computation that cannot be and is not
>>> aborted?
>>
>> No, I am not saying that.  Which of a, b or c do you deny?
>>
>
> I already answered that, you have to pay attention to what I say BEFORE
> you try to form a rebuttal.
>
> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>
> The execution of Ĥ is computationally distinct from the simulation of
> ⟨Ĥ1⟩ ⟨Ĥ2⟩ by the simulating halt decider at Ĥ.qx so the fact that Ĥ.qx
> transitions to its final state of Ĥ.qn does not contradict the fact that
> Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ correctly decides that its input never halts.

It may be executionally distinct, but if it is the same algorithm/input
combination then it MUST produce the same answer or the algorithm does
not form a proper computation and thus you do not meet the requerements
to be a Halt Decider.

>
> THIS SEEMS BEYOND YOUR CAPACITY TO COMPREHEND:
> The executed instances of Ĥ are not under the dominion of a simulating
> halt decider that can abort them before they get started. This
> conclusively proves that they can have different behavior without
> forming any contradiction.
>

Yes, The Halt Decider can do what ever it wants to its simulation, but
the simulation (since H is NOT a UTM) doesn't matter as far as what the
right answer is, as that right answer is based on the behavior of the
ACTUAL Machine/Input that H was given a representation of, or
equivalently what an actual UTM would produce from that same input,
since that BY DEFINITION will be identical.

H can affect/have dominion of the simulation, but that doesn't mean
anything. As I said, in actuality the Machine has Dominion over the
simulation as the machine defines what the right answer is that the
simulation must try to find.

So yes, H can simulate its input to a not-yet-halted state, but that
doesn't change the right answer as the Machine it was given a
representation of is still Halting, and H's simulation can't change that.

The answer H give to its caller will, but you have already decided that
H is going to return non-halting, and if you change that you need to
start all over as any change to H creates a new H^ so all the work on
proving has to start over.

> Deceptive double-talk may fool the the gullible ignorant ones especially
> if you dishonestly make sure to erase the context that you are
> responding to.
>

On 8/22/21 4:06 PM, olcott wrote:
> On 8/22/2021 2:46 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>> (anything to avoid addressing the incontrovertible facts)
>>
>>> On 8/22/2021 2:00 PM, Ben Bacarisse wrote:
>>
>>>>>> a. The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation of your Ĥ applied to
>>>>>> ⟨Ĥ⟩.
>>>>>> b. Your Ĥ applied to ⟨Ĥ⟩ halts.
>>>>>> c. Your H rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩ when it should accept it.
>>>>
>>>> I take it you agree with a, b and c since you make no comment about
>>>> them.  If you do not agree, you need to say which ones you disagree
>>>> with.
>>
>> You have not said which of a, b or c you deny.  I don't want to put
>> words in your mouth (what sort of person would do that, eh?) but I will
>> have to assume you agree with them all if you don't say.
>>
>
> As I have already explained in complete detail your simplistic analysis
> conflates together two distinctly different computations:
> (1) Executed Ĥ applied to ⟨Ĥ⟩ // can't be aborted
>
> (2) Simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ by a simulating halt decider
> // can be and is aborted.
>
> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>
> The execution of Ĥ is computationally distinct from the simulation of
> ⟨Ĥ1⟩ ⟨Ĥ2⟩ by the simulating halt decider at Ĥ.qx so the fact that Ĥ.qx
> transitions to its final state of Ĥ.qn does not contradict the fact that
> Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ correctly decides that its input never halts.
>
> THIS SEEMS BEYOND YOUR CAPACITY TO COMPREHEND:
> The executed instances of Ĥ are not under the dominion of a simulating
> halt decider that can abort them before they get started. This
> conclusively proves that they can have different behavior without
> forming any contradiction.
>

Rebutted in another thread.

All H^(<H^>) must give the same answer and all H(<H^>,<H^>) must give
the same answer or you have broken the fundamental requirements for the
proof.

olcott <NoOne@NoWhere.com> writes:

> On 8/22/2021 2:41 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/22/2021 1:56 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> The executed instances of H(P,P) are distinctly different
>>>>> computations...
>>>> More deflection. Here's why you are wrong:
>>>> a. The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation of your Ĥ applied to ⟨Ĥ⟩.
>>>> b. Your Ĥ applied to ⟨Ĥ⟩ halts.
>>>> c. Your H rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩ when it should accept it.
>>>> Which of these facts do you deny?
>>>
>>> So in other words you are saying that a computation that can be and is
>>> aborted is exactly the same as a computation that cannot be and is not
>>> aborted?
>>
>> No, I am not saying that. Which of a, b or c do you deny?
>
> I already answered that,

No you didn't (but do point me to where you said it if I've got that
wrong). You did say "⟨Ĥ⟩ ⟨Ĥ⟩ does not encode a halting computation" but
you won't say which of a, b or c is wrong. Your problem is that you
can't reject any of them because you know they are all simple facts.

I am pretty sure you will neither accept a, b and c nor say which you
reject, but everyone else can see that they neatly summarise why your H
is not a halt decider, at least for the key case you've wasted 17 years
"studying".

--
Ben.

olcott <NoOne@NoWhere.com> writes:

> On 8/22/2021 2:46 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>> (anything to avoid addressing the incontrovertible facts)
>>
>>> On 8/22/2021 2:00 PM, Ben Bacarisse wrote:
>>
>>>>>> a. The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation of your Ĥ applied to ⟨Ĥ⟩.
>>>>>> b. Your Ĥ applied to ⟨Ĥ⟩ halts.
>>>>>> c. Your H rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩ when it should accept it.
>>>>
>>>> I take it you agree with a, b and c since you make no comment about
>>>> them. If you do not agree, you need to say which ones you disagree
>>>> with.
>> You have not said which of a, b or c you deny. I don't want to put
>> words in your mouth (what sort of person would do that, eh?) but I will
>> have to assume you agree with them all if you don't say.
>
> As I have already explained in complete detail your simplistic
> analysis conflates together two distinctly different computations:

So which of a, b or c is wrong? I can't work it out from the text below
because you use undefined terms and impart agency to mathematical
functions in phrases like "can't be aborted".

--
Ben.

On 8/22/2021 3:47 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/22/2021 2:41 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/22/2021 1:56 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> The executed instances of H(P,P) are distinctly different
>>>>>> computations...
>>>>> More deflection. Here's why you are wrong:
>>>>> a. The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation of your Ĥ applied to ⟨Ĥ⟩.

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn

When this ⟨Ĥ⟩ ⟨Ĥ⟩ refers to the executed Ĥ on input ⟨Ĥ⟩ it halts.

When this ⟨Ĥ⟩ ⟨Ĥ⟩ refers to ⟨Ĥ1⟩ ⟨Ĥ2⟩ simulated by simulating halt
decider at Ĥ.qx it never halts.

You are conflating two distinctly different computations together.

The execution of Ĥ is not under the dominion of a halt decider.
The simulation of ⟨Ĥ1⟩ is under the dominion of a halt decider.

Your capacity for understanding these nuances seems quite limited.

--
Copyright 2021 Pete Olcott

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

On 8/22/2021 4:03 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/22/2021 2:46 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>> (anything to avoid addressing the incontrovertible facts)
>>>
>>>> On 8/22/2021 2:00 PM, Ben Bacarisse wrote:
>>>
>>>>>>> a. The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation of your Ĥ applied to ⟨Ĥ⟩.
>>>>>>> b. Your Ĥ applied to ⟨Ĥ⟩ halts.
>>>>>>> c. Your H rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩ when it should accept it.
>>>>>
>>>>> I take it you agree with a, b and c since you make no comment about
>>>>> them. If you do not agree, you need to say which ones you disagree
>>>>> with.
>>> You have not said which of a, b or c you deny. I don't want to put
>>> words in your mouth (what sort of person would do that, eh?) but I will
>>> have to assume you agree with them all if you don't say.
>>
>> As I have already explained in complete detail your simplistic
>> analysis conflates together two distinctly different computations:
>
> So which of a, b or c is wrong? I can't work it out from the text below
> because you use undefined terms and impart agency to mathematical
> functions in phrases like "can't be aborted".
>

You are too stupid to understand that "can't be aborted" means that the
code to abort the computation does not exist?

--
Copyright 2021 Pete Olcott

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

On 8/22/2021 4:18 PM, olcott wrote:
> On 8/22/2021 4:03 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/22/2021 2:46 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>> (anything to avoid addressing the incontrovertible facts)
>>>>
>>>>> On 8/22/2021 2:00 PM, Ben Bacarisse wrote:
>>>>
>>>>>>>> a. The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation of your Ĥ applied
>>>>>>>> to ⟨Ĥ⟩.
>>>>>>>> b. Your Ĥ applied to ⟨Ĥ⟩ halts.
>>>>>>>> c. Your H rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩ when it should accept it.
>>>>>>
>>>>>> I take it you agree with a, b and c since you make no comment about
>>>>>> them.  If you do not agree, you need to say which ones you disagree
>>>>>> with.
>>>> You have not said which of a, b or c you deny.  I don't want to put
>>>> words in your mouth (what sort of person would do that, eh?) but I will
>>>> have to assume you agree with them all if you don't say.
>>>
>>> As I have already explained in complete detail your simplistic
>>> analysis conflates together two distinctly different computations:
>>
>> So which of a, b or c is wrong?  I can't work it out from the text below
>> because you use undefined terms and impart agency to mathematical
>> functions in phrases like "can't be aborted".
>>
>
> You are too stupid to understand that "can't be aborted" means that the
> code to abort the computation does not exist?
>

I honestly don't believe that you really are too stupid to understand
that "can't be aborted" means that the code to abort the computation
does not exist.

I called you stupid to get you to stop playing head games. If the issue
really is one of IQ, then I humbly apologize for calling you stupid.

--
Copyright 2021 Pete Olcott

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

On 8/22/21 5:11 PM, olcott wrote:
> On 8/22/2021 3:47 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/22/2021 2:41 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/22/2021 1:56 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> The executed instances of H(P,P) are distinctly different
>>>>>>> computations...
>>>>>> More deflection.  Here's why you are wrong:
>>>>>> a. The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation of your Ĥ applied to
>>>>>> ⟨Ĥ⟩.
>
> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>
> When this ⟨Ĥ⟩ ⟨Ĥ⟩ refers to the executed Ĥ on input ⟨Ĥ⟩ it halts.
>
> When this ⟨Ĥ⟩ ⟨Ĥ⟩ refers to ⟨Ĥ1⟩ ⟨Ĥ2⟩ simulated by simulating halt
> decider at Ĥ.qx it never halts.
>

No, it is simulated to a Not-Yet-Halted state.

You didn't make it to 'Never', Never is a very long time. From previous
reports, you only made it 27 steps.

Showing Non-Halting by simulating requires simulating for an unbounded
number of states. (Or Sound Logic, like not assuming that the copy of H
behaves differently than it does).

> You are conflating two distinctly different computations together.

If they represent that same Machine code, then MUST be identical.
>
> The execution of Ĥ is not under the dominion of a halt decider.
> The simulation of ⟨Ĥ1⟩ is under the dominion of a halt decider.

The simulation is, but not the machine the input represents.

Important difference.

>
> Your capacity for understanding these nuances seems quite limited.
>
>

YOU capacity is limited.

On 8/22/21 5:18 PM, olcott wrote:
> On 8/22/2021 4:03 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/22/2021 2:46 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>> (anything to avoid addressing the incontrovertible facts)
>>>>
>>>>> On 8/22/2021 2:00 PM, Ben Bacarisse wrote:
>>>>
>>>>>>>> a. The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation of your Ĥ applied
>>>>>>>> to ⟨Ĥ⟩.
>>>>>>>> b. Your Ĥ applied to ⟨Ĥ⟩ halts.
>>>>>>>> c. Your H rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩ when it should accept it.
>>>>>>
>>>>>> I take it you agree with a, b and c since you make no comment about
>>>>>> them.  If you do not agree, you need to say which ones you disagree
>>>>>> with.
>>>> You have not said which of a, b or c you deny.  I don't want to put
>>>> words in your mouth (what sort of person would do that, eh?) but I will
>>>> have to assume you agree with them all if you don't say.
>>>
>>> As I have already explained in complete detail your simplistic
>>> analysis conflates together two distinctly different computations:
>>
>> So which of a, b or c is wrong?  I can't work it out from the text below
>> because you use undefined terms and impart agency to mathematical
>> functions in phrases like "can't be aborted".
>>
>
> You are too stupid to understand that "can't be aborted" means that the
> code to abort the computation does not exist?
>

So, are you saying that you H now has no code to abort its simulation?

Remember, H^ must be built from the same code as the H that it is
confounding.

Or, are we back to the meanless case of Ha(<Hn^>,<Hn^) getting the right
answer while it get the wrong answer to Ha(<Ha^>,<Ha^>)?

olcott <NoOne@NoWhere.com> writes:

> On 8/22/2021 3:09 PM, Ben Bacarisse wrote:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/19/2021 8:14 AM, Ben Bacarisse wrote:
>>
>>>>> Your mission, should you chose to accept it, is to write a return
>>>>> decider B with this prototype
>>>>>
>>>>> typedef uintptr_t data;
>>>>> typedef void (*function)(data);
>>>>> extern _Bool B(function, data);
>>>>>
>>>>> such that B(f, d) returns true if and only if a call of f from main with
>>>>> argument d returns to main. The two arguments, f and d, are said to
>>>>> represenet the call expression f(d).
>>>>>
>>>>> If, rather than just thinking you can do this, you have actual C code,
>>>>> you should provide either source or a compiled translation unit that can
>>>>> be linked with this one:
>>>>>
>>>>> #include <stdint.h>
>>>>> #include <stdio.h>
>>>>>
>>>>> typedef uintptr_t data;
>>>>> typedef void (*function)(data);
>>>>>
>>>>> extern _Bool B(function, data);
>>>>> void B_hat(data x) { if (B((function)x, x)) while (1); }
>>>>> int main(void)
>>>>> {
>>>>> printf("%d\n", B(B_hat, (data)B_hat));
>>>>> fflush(stdout);
>>>>> B_hat((data)B_hat);
>>>>> puts("returned");
>>>>> }
>>>>>
>>>>> The output should be either
>>>>>
>>>>> 1
>>>>> returned
>>>>>
>>>>> or
>>>>>
>>>>> 0
>>>>>
>>>>> with no further output. Of course you could always just agree that no
>>>>> such function B can be written.
>>
>>>> #include <stdint.h>
>>>> #include <stdio.h>
>>>>
>>>> typedef uintptr_t data;
>>>> typedef void (*function)(data);
>>>>
>>>> extern _Bool B(function, data);
>>>>
>>>> void B_hat(data x) { if (H((u32)x, (u32)x)) while (1); }
>>>>
>>>> int main2()
>>>> {
>>>> OutputHex(H((u32)B_hat, (u32)B_hat));
>>>> B_hat((u32)B_hat);
>>>> OutputString("returned");
>>>> }
>>>
>>> This shows no function B. And it's not even valid C. How does it help
>>> meet the challenge?
>>
>>>> machine stack stack machine assembly
>>>> address address data code language
>>>> ======== ======== ======== ========= =============
>>>> ...[00000f6c][00101c0a][00000000] 55 push ebp
>> Long trace including output:
>>
>>>> 0
>> ... and ...
>>>> returned
>>
>>> B does not do what is required of it to meet my specification. I am
>>> sure it meets yours but that was not the challenge.
>> To wrap up this sub-thread, let's just say that you currently can't see
>> how to meet my specification.
>
> Let's just say that it is not cost effective for me to untangle any
> more convoluted paraphrase of the exact same things that I have
> already been saying without a specific high level overview of material
> differences that seem to be non-existent.

I wondered why you posted a trace showing the wrong behaviour, but now I
know. The two permissible outputs I showed made things too convoluted
for you to know your code did not produce one or other of them!

--
Ben.

olcott <NoOne@NoWhere.com> writes:

> On 8/22/2021 3:47 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/22/2021 2:41 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/22/2021 1:56 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> The executed instances of H(P,P) are distinctly different
>>>>>>> computations...
>>>>>> More deflection. Here's why you are wrong:
>>>>>> a. The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation of your Ĥ applied to ⟨Ĥ⟩.
>
> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>
> When this ⟨Ĥ⟩ ⟨Ĥ⟩ refers to the executed Ĥ on input ⟨Ĥ⟩ it halts.
>
> When this ⟨Ĥ⟩ ⟨Ĥ⟩ refers to ⟨Ĥ1⟩ ⟨Ĥ2⟩ simulated by simulating halt
> decider at Ĥ.qx it never halts.

This suggests that you think a string can encode two different
computations. I am reluctant to think that is really what you mean
because it's beyond daft.

But thank you for almost answering my question. It seems to be fact 'a'
you reject. So, in PO-land, what string does uniquely encode the
computation of Ĥ applied to ⟨Ĥ⟩ if not the string ⟨Ĥ⟩ ⟨Ĥ⟩? To everyone
else, (a) is simply a fact about how the halting problem is defined.

> You are conflating two distinctly different computations together.

So what two strings encode these two (supposedly) different
computations? The strings ⟨Ĥ⟩ ⟨Ĥ⟩ and ⟨Ĥ1⟩ ⟨Ĥ2⟩ are identical and
encode the halting computation of Ĥ applied to ⟨Ĥ⟩.

Is this partly why you've consistently failed to be open about the fact
that all the ⟨Ĥi⟩ are identical to ⟨Ĥ⟩?

--
Ben.

olcott <NoOne@NoWhere.com> writes:

> On 8/22/2021 4:03 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/22/2021 2:46 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>> (anything to avoid addressing the incontrovertible facts)
>>>>
>>>>> On 8/22/2021 2:00 PM, Ben Bacarisse wrote:
>>>>
>>>>>>>> a. The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation of your Ĥ applied to ⟨Ĥ⟩.
>>>>>>>> b. Your Ĥ applied to ⟨Ĥ⟩ halts.
>>>>>>>> c. Your H rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩ when it should accept it.
>>>>>>
>>>>>> I take it you agree with a, b and c since you make no comment about
>>>>>> them. If you do not agree, you need to say which ones you disagree
>>>>>> with.
>>>> You have not said which of a, b or c you deny. I don't want to put
>>>> words in your mouth (what sort of person would do that, eh?) but I will
>>>> have to assume you agree with them all if you don't say.
>>>
>>> As I have already explained in complete detail your simplistic
>>> analysis conflates together two distinctly different computations:
>> So which of a, b or c is wrong? I can't work it out from the text below
>> because you use undefined terms and impart agency to mathematical
>> functions in phrases like "can't be aborted".
>
> You are too stupid to understand that "can't be aborted" means that
> the code to abort the computation does not exist?

No. But I refuse to play games with words. I have tried, many times,
to give you the words to say what you mean but you haven't taken to that
because, I am now sure, you /want/ the ambiguity and the vagueness. You
want "stopping" and "aborting" to be maybe not quite entirely unlike not
halting because you know that clarity is your enemy.

Anyway, thanks for halt-answering my question in another post. It seems
it's fact (a) you reject.

--
Ben.

olcott <NoOne@NoWhere.com> writes:

> I called you stupid to get you to stop playing head games. If the
> issue really is one of IQ, then I humbly apologize for calling you
> stupid.

Oh, how sweet! A back-handed insult dressed up as if you are trying to
be nice!

--
Ben.

On 8/22/2021 5:17 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/22/2021 3:09 PM, Ben Bacarisse wrote:
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/19/2021 8:14 AM, Ben Bacarisse wrote:
>>>
>>>>>> Your mission, should you chose to accept it, is to write a return
>>>>>> decider B with this prototype
>>>>>>
>>>>>> typedef uintptr_t data;
>>>>>> typedef void (*function)(data);
>>>>>> extern _Bool B(function, data);
>>>>>>
>>>>>> such that B(f, d) returns true if and only if a call of f from main with
>>>>>> argument d returns to main. The two arguments, f and d, are said to
>>>>>> represenet the call expression f(d).
>>>>>>
>>>>>> If, rather than just thinking you can do this, you have actual C code,
>>>>>> you should provide either source or a compiled translation unit that can
>>>>>> be linked with this one:
>>>>>>
>>>>>> #include <stdint.h>
>>>>>> #include <stdio.h>
>>>>>>
>>>>>> typedef uintptr_t data;
>>>>>> typedef void (*function)(data);
>>>>>>
>>>>>> extern _Bool B(function, data);
>>>>>> void B_hat(data x) { if (B((function)x, x)) while (1); }
>>>>>> int main(void)
>>>>>> {
>>>>>> printf("%d\n", B(B_hat, (data)B_hat));
>>>>>> fflush(stdout);
>>>>>> B_hat((data)B_hat);
>>>>>> puts("returned");
>>>>>> }
>>>>>>
>>>>>> The output should be either
>>>>>>
>>>>>> 1
>>>>>> returned
>>>>>>
>>>>>> or
>>>>>>
>>>>>> 0
>>>>>>
>>>>>> with no further output. Of course you could always just agree that no
>>>>>> such function B can be written.
>>>
>>>>> #include <stdint.h>
>>>>> #include <stdio.h>
>>>>>
>>>>> typedef uintptr_t data;
>>>>> typedef void (*function)(data);
>>>>>
>>>>> extern _Bool B(function, data);
>>>>>
>>>>> void B_hat(data x) { if (H((u32)x, (u32)x)) while (1); }
>>>>>
>>>>> int main2()
>>>>> {
>>>>> OutputHex(H((u32)B_hat, (u32)B_hat));
>>>>> B_hat((u32)B_hat);
>>>>> OutputString("returned");
>>>>> }
>>>>
>>>> This shows no function B. And it's not even valid C. How does it help
>>>> meet the challenge?
>>>
>>>>> machine stack stack machine assembly
>>>>> address address data code language
>>>>> ======== ======== ======== ========= =============
>>>>> ...[00000f6c][00101c0a][00000000] 55 push ebp
>>> Long trace including output:
>>>
>>>>> 0
>>> ... and ...
>>>>> returned
>>>
>>>> B does not do what is required of it to meet my specification. I am
>>>> sure it meets yours but that was not the challenge.
>>> To wrap up this sub-thread, let's just say that you currently can't see
>>> how to meet my specification.
>>
>> Let's just say that it is not cost effective for me to untangle any
>> more convoluted paraphrase of the exact same things that I have
>> already been saying without a specific high level overview of material
>> differences that seem to be non-existent.
>
> I wondered why you posted a trace showing the wrong behaviour,

It is the actual behavior that the code specifies.

< but now I
> know. The two permissible outputs I showed made things too convoluted
> for you to know your code did not produce one or other of them!
>

--
Copyright 2021 Pete Olcott

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

On 8/22/2021 5:44 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/22/2021 3:47 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/22/2021 2:41 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 8/22/2021 1:56 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> The executed instances of H(P,P) are distinctly different
>>>>>>>> computations...
>>>>>>> More deflection. Here's why you are wrong:
>>>>>>> a. The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation of your Ĥ applied to ⟨Ĥ⟩.
>>
>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>
>> When this ⟨Ĥ⟩ ⟨Ĥ⟩ refers to the executed Ĥ on input ⟨Ĥ⟩ it halts.
>>
>> When this ⟨Ĥ⟩ ⟨Ĥ⟩ refers to ⟨Ĥ1⟩ ⟨Ĥ2⟩ simulated by simulating halt
>> decider at Ĥ.qx it never halts.
>
> This suggests that you think a string can encode two different
> computations. I am reluctant to think that is really what you mean
> because it's beyond daft.
>

The first Ĥ is essentially a recursive invocation at the outermost level
of recursion depth of 0. The simulation at Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ is essentially
the next level of recursion depth of 1.

Although it may be difficult to understand that these essentially
specify two different recursion depths you do understand that the
recursive invocation of the same function does have a different state at
two different recursion depths, don't you?

int Factorial(int n)
{ Output("Factorial(n)",n);
if (n > 1)
return n * Factorial(n - 1);
else
return 1;
}

Factorial(3) has a different state the first time that it is call than
it has recursive invocation of: Factorial(n - 1). Do you understand this?

> But thank you for almost answering my question. It seems to be fact 'a'
> you reject. So, in PO-land, what string does uniquely encode the
> computation of Ĥ applied to ⟨Ĥ⟩ if not the string ⟨Ĥ⟩ ⟨Ĥ⟩? To everyone
> else, (a) is simply a fact about how the halting problem is defined.
>
>> You are conflating two distinctly different computations together.
>
> So what two strings encode these two (supposedly) different
> computations? The strings ⟨Ĥ⟩ ⟨Ĥ⟩ and ⟨Ĥ1⟩ ⟨Ĥ2⟩ are identical and
> encode the halting computation of Ĥ applied to ⟨Ĥ⟩.
>
> Is this partly why you've consistently failed to be open about the fact
> that all the ⟨Ĥi⟩ are identical to ⟨Ĥ⟩?
>

--
Copyright 2021 Pete Olcott

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

On 8/22/2021 5:51 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/22/2021 4:03 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/22/2021 2:46 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>> (anything to avoid addressing the incontrovertible facts)
>>>>>
>>>>>> On 8/22/2021 2:00 PM, Ben Bacarisse wrote:
>>>>>
>>>>>>>>> a. The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation of your Ĥ applied to ⟨Ĥ⟩.
>>>>>>>>> b. Your Ĥ applied to ⟨Ĥ⟩ halts.
>>>>>>>>> c. Your H rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩ when it should accept it.
>>>>>>>
>>>>>>> I take it you agree with a, b and c since you make no comment about
>>>>>>> them. If you do not agree, you need to say which ones you disagree
>>>>>>> with.
>>>>> You have not said which of a, b or c you deny. I don't want to put
>>>>> words in your mouth (what sort of person would do that, eh?) but I will
>>>>> have to assume you agree with them all if you don't say.
>>>>
>>>> As I have already explained in complete detail your simplistic
>>>> analysis conflates together two distinctly different computations:
>>> So which of a, b or c is wrong? I can't work it out from the text below
>>> because you use undefined terms and impart agency to mathematical
>>> functions in phrases like "can't be aborted".
>>
>> You are too stupid to understand that "can't be aborted" means that
>> the code to abort the computation does not exist?
>
> No. But I refuse to play games with words.

If you really want to have an honest dislogue then you would paraphrase
what you thing that I mean instead of saying that an entirely paragraph
makes no sense at all because it contains one difficult phrase.

> I have tried, many times,
> to give you the words to say what you mean but you haven't taken to that
> because, I am now sure, you /want/ the ambiguity and the vagueness. You

I don't want vagueness. The words that you say are impossibly difficult
words to you are very obviously trivial to me.

Because Richard can't seem to ever be able to understand what the words
"before" and "after" mean, I have totally given up with his head games.

> want "stopping" and "aborting" to be maybe not quite entirely unlike not
> halting because you know that clarity is your enemy.

When a computation is forced to stop running this is an entirely
different thing than a computation that stops running because it is has
completed all of its steps. If we allow this ambiguity to remain then
disingenuous double talk seems more plausible.

>
> Anyway, thanks for halt-answering my question in another post. It seems
> it's fact (a) you reject.
>

--
Copyright 2021 Pete Olcott

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

On 8/22/2021 5:57 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> I called you stupid to get you to stop playing head games. If the
>> issue really is one of IQ, then I humbly apologize for calling you
>> stupid.
>
> Oh, how sweet! A back-handed insult dressed up as if you are trying to
> be nice!
>

I think that your intelligence is sufficient to validate my work. I may
have overestimated the breadth of your knowledge.

--
Copyright 2021 Pete Olcott

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

On 8/22/21 10:17 PM, olcott wrote:
> On 8/22/2021 5:44 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/22/2021 3:47 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/22/2021 2:41 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 8/22/2021 1:56 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> The executed instances of H(P,P) are distinctly different
>>>>>>>>> computations...
>>>>>>>> More deflection.  Here's why you are wrong:
>>>>>>>> a. The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation of your Ĥ applied
>>>>>>>> to ⟨Ĥ⟩.
>>>
>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>
>>> When this ⟨Ĥ⟩ ⟨Ĥ⟩ refers to the executed Ĥ on input ⟨Ĥ⟩ it halts.
>>>
>>> When this ⟨Ĥ⟩ ⟨Ĥ⟩ refers to ⟨Ĥ1⟩ ⟨Ĥ2⟩ simulated by simulating halt
>>> decider at Ĥ.qx it never halts.
>>
>> This suggests that you think a string can encode two different
>> computations.  I am reluctant to think that is really what you mean
>> because it's beyond daft.
>>
>
> The first Ĥ is essentially a recursive invocation at the outermost level
> of recursion depth of 0. The simulation at Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ is essentially
> the next level of recursion depth of 1.
>
> Although it may be difficult to understand that these essentially
> specify two different recursion depths you do understand that the
> recursive invocation of the same function does have a different state at
> two different recursion depths, don't you?
>

Then YOU don't understand that BY DEFINITION a Computation must ALWAYS
generate the same result regaurdless of the environment it is executed in.

If it doesn't, then BY DEFINITION what you have are NOT Computations,
and thus your WHOLE PROOF is INVALID.

> int Factorial(int n)
> {
>   Output("Factorial(n)",n);
>   if (n > 1)
>     return n * Factorial(n - 1);
>   else
>     return 1;
> }
>
> Factorial(3) has a different state the first time that it is call than
> it has recursive invocation of: Factorial(n - 1). Do you understand this?

But the second call isn't Factorial(3) but Factorial(2) so that is a
different case, and allowed to give different results.

is <H^1> a different value than <H^2>?

If so then you code has a bug in its 'copy' routine.

Again, a fatal flaw in your proof.

>
>> But thank you for almost answering my question.  It seems to be fact 'a'
>> you reject.  So, in PO-land, what string does uniquely encode the
>> computation of Ĥ applied to ⟨Ĥ⟩ if not the string ⟨Ĥ⟩ ⟨Ĥ⟩?  To everyone
>> else, (a) is simply a fact about how the halting problem is defined.
>>
>>> You are conflating two distinctly different computations together.
>>
>> So what two strings encode these two (supposedly) different
>> computations?  The strings ⟨Ĥ⟩ ⟨Ĥ⟩ and ⟨Ĥ1⟩ ⟨Ĥ2⟩ are identical and
>> encode the halting computation of Ĥ applied to ⟨Ĥ⟩.
>>
>> Is this partly why you've consistently failed to be open about the fact
>> that all the ⟨Ĥi⟩ are identical to ⟨Ĥ⟩?
>>
>
>

On 8/22/21 10:30 PM, olcott wrote:
> On 8/22/2021 5:51 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/22/2021 4:03 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/22/2021 2:46 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>> (anything to avoid addressing the incontrovertible facts)
>>>>>>
>>>>>>> On 8/22/2021 2:00 PM, Ben Bacarisse wrote:
>>>>>>
>>>>>>>>>> a. The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation of your Ĥ
>>>>>>>>>> applied to ⟨Ĥ⟩.
>>>>>>>>>> b. Your Ĥ applied to ⟨Ĥ⟩ halts.
>>>>>>>>>> c. Your H rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩ when it should accept it.
>>>>>>>>
>>>>>>>> I take it you agree with a, b and c since you make no comment about
>>>>>>>> them.  If you do not agree, you need to say which ones you disagree
>>>>>>>> with.
>>>>>> You have not said which of a, b or c you deny.  I don't want to put
>>>>>> words in your mouth (what sort of person would do that, eh?) but I
>>>>>> will
>>>>>> have to assume you agree with them all if you don't say.
>>>>>
>>>>> As I have already explained in complete detail your simplistic
>>>>> analysis conflates together two distinctly different computations:
>>>> So which of a, b or c is wrong?  I can't work it out from the text
>>>> below
>>>> because you use undefined terms and impart agency to mathematical
>>>> functions in phrases like "can't be aborted".
>>>
>>> You are too stupid to understand that "can't be aborted" means that
>>> the code to abort the computation does not exist?
>>
>> No.  But I refuse to play games with words.
>
> If you really want to have an honest dislogue then you would paraphrase
> what you thing that I mean instead of saying that an entirely paragraph
> makes no sense at all because it contains one difficult phrase.
>
>>  I have tried, many times,
>> to give you the words to say what you mean but you haven't taken to that
>> because, I am now sure, you /want/ the ambiguity and the vagueness.  You
>
> I don't want vagueness. The words that you say are impossibly difficult
> words to you are very obviously trivial to me.
>
> Because Richard can't seem to ever be able to understand what the words
> "before" and "after" mean, I have totally given up with his head games.

I perfectly well know what the words MEAN.

I don't accept that something can be an attribute that is defined with
an ALWAYS attribute can be mixed with things like before or after.

Just like a cat that was living before it was killed by being hit by the
car can be considered living after that, or even could be considered as
if it was acting like it was immortal before it was killed, so we can
use arguments that would be true only for an immortal being, we can't
consider H to be actually a 'Pure Simulator' just because it acts
similar to one for a while, and then breaks the rules for being one.

FAIL.

>
>> want "stopping" and "aborting" to be maybe not quite entirely unlike not
>> halting because you know that clarity is your enemy.
>
> When a computation is forced to stop running this is an entirely
> different thing than a computation that stops running because it is has
> completed all of its steps. If we allow this ambiguity to remain then
> disingenuous double talk seems more plausible.
>
>

Right, a Simulation of a Representation of a Computation that is forced
to stop running no longer represents the actual b4ehavior of that
Computation. The Behavior of the Computation that was represented is
STILL The behavior of the actual Computation as allowed to freely run.

The Simulation just doesn't demonstrate that anymore.

I.E. The fact that H aborted its simulation of H^(<H^>) from its given
input <H^>,<H^> doesn't change the fact that H^<<H^> WILL Halt after a
given number of steps. The fact that it stopped simulating at a lower
number does not change that an make the machine non-halting, it only
show a simulation in a not-yet-halted state.

>
>>
>> Anyway, thanks for halt-answering my question in another post.  It seems
>> it's fact (a) you reject.
>>
>
>

olcott <NoOne@NoWhere.com> writes:

> On 8/22/2021 5:17 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/22/2021 3:09 PM, Ben Bacarisse wrote:

>>>> To wrap up this sub-thread, let's just say that you currently can't see
>>>> how to meet my specification.
>>>
>>> Let's just say that it is not cost effective for me to untangle any
>>> more convoluted paraphrase of the exact same things that I have
>>> already been saying without a specific high level overview of material
>>> differences that seem to be non-existent.
>>
>> I wondered why you posted a trace showing the wrong behaviour,
>
> It is the actual behavior that the code specifies.

A rather obvious thing to say. Code does what it does. It's the
behaviour I specified that's impossible. No algorithm can determine
that a function call will return just as no algorithm can determine if a
program will halt.

--
Ben.

olcott <NoOne@NoWhere.com> writes:

> On 8/22/2021 5:44 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/22/2021 3:47 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/22/2021 2:41 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 8/22/2021 1:56 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> The executed instances of H(P,P) are distinctly different
>>>>>>>>> computations...
>>>>>>>> More deflection. Here's why you are wrong:
>>>>>>>> a. The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation of your Ĥ applied to ⟨Ĥ⟩.
>>>
>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>
>>> When this ⟨Ĥ⟩ ⟨Ĥ⟩ refers to the executed Ĥ on input ⟨Ĥ⟩ it halts.
>>>
>>> When this ⟨Ĥ⟩ ⟨Ĥ⟩ refers to ⟨Ĥ1⟩ ⟨Ĥ2⟩ simulated by simulating halt
>>> decider at Ĥ.qx it never halts.
>>
>> This suggests that you think a string can encode two different
>> computations. I am reluctant to think that is really what you mean
>> because it's beyond daft.
>
> The first Ĥ is essentially a recursive invocation at the outermost
> level of recursion depth of 0. The simulation at Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ is
> essentially the next level of recursion depth of 1.

Glossing over the metaphorical use of "recursion", yes.

> Although it may be difficult to understand that these essentially
> specify two different recursion depths you do understand that the
> recursive invocation of the same function does have a different state
> at two different recursion depths, don't you?

I started to answer, with a detailed explanation of TM configurations,
but then got fed up with your patronising tone.

How is the computation of Ĥ applied to ⟨Ĥ⟩ encoded as a string so that
it can given on the tape to a halt decider?

Correct answer: ⟨Ĥ⟩ ⟨Ĥ⟩.
PO-answer: ?

Can the string ⟨Ĥ⟩ ⟨Ĥ⟩ encode any other computation?

Correct answer: no.
PO-answer: ?

Are the all the strings ⟨Ĥi⟩ identical to ⟨Ĥ⟩?

Correct answer: yes.
PO-answer: ?

Can the string ⟨Ĥ⟩ ⟨Ĥ⟩ (or ⟨Ĥ1⟩ ⟨Ĥ2⟩ or ⟨Ĥ17⟩ ⟨Ĥ23⟩ for that matter)
encode anything other than the halting computation Ĥ applied to ⟨Ĥ⟩?

Correct answer: no.
PO-answer: ?

Should a halt decide accept or reject the string ⟨Ĥ⟩ ⟨Ĥ⟩?

Correct answer: it should accept it.
PO-answer: it should reject it.

Is PO's H a halt decider, at least as far as this one case is concerned?

Correct answer: no, it's wrong about the instance ⟨Ĥ⟩ ⟨Ĥ⟩.
PO-Answer: yes, because Ĥ applied to ⟨Ĥ⟩ only halts for reasons I
consider to be very special.

--
Ben.