On 2021-11-23 22:48, olcott wrote:
> On 11/23/2021 10:18 PM, André G. Isaak wrote:
>> On 2021-11-23 21:03, olcott wrote:
>>> On 11/23/2021 9:44 PM, André G. Isaak wrote:
>>>> On 2021-11-23 20:24, olcott wrote:
>>>>> On 11/23/2021 8:22 PM, André G. Isaak wrote:
>>>>>> On 2021-11-23 18:53, olcott wrote:
>>>>>>> On 11/23/2021 7:34 PM, André G. Isaak wrote:
>>>>>
>>>>>> Crucially, the halting function exists *independently* and *prior*
>>>>>> to any Turing Machine which attempts to compute this function. The
>>>>>> halting function is *not* associated with any sort of algorithm;
>>>>>> it is simply a mapping. In other words it is simply a denumerably
>>>>>> infinite list of all possible computations and their halting
>>>>>> status expressed as ordered pairs.
>>>>>>
>>>>>
>>>>>
>>>>> You don't realize it but you are asking a decider to make its
>>>>> decision on the basis of a hypothetical string that does not
>>>>> actually exist.
>>>>
>>>> ???
>>>>
>>>> So now you claim the STRING <P> <P> can't exist? But at the same
>>>> time you claim that your H1 returns the correct answer for this
>>>> allegedly impossible string? How on earth does that work.
>>>>
>>>
>>> int H(ptr x, ptr y) { x(y); }
>>> int H1(ptr x, ptr y) { x(y); int P(ptr x) { H(x, x); }
>>> int P1(ptr x) { H1(x, x); }
>>
>>
>> What does any of this have to do with your ridiculous claim that the
>> string <P> <P> does not actually exist?
>
> If you want the actual behavior of P(P) run independently
> then you have to change P or H into something that they are not
> because they are defined with hardwired inter-dependency.

If you want the actual behaviour of P(P) run independently, you simply
run P(P) independently.

I think what you mean to say is if you want H to give you the correct
answer about the actual behaviour of P(P) run independently, which it
can't. The interdependency prevents this.

But that does not change the fact that the computation P(P) halts, and
that this therefore is the only correct answer to the question which a
halt decider is required to answer. It can't get that answer, but that's
the whole point. Your H cannot correctly decide P(P) just as Linz
claims. You can't claim it gets P(P) right by attempting to change the
question.

> You can imagine a P that does not call H(P1,P1)
> That is not the actual P it is only imaginary.
>
> or you could imaging an H1(P,P) that is not called by P
> That is not the actual H it is only imaginary.
>
> When we take the actual H and the actual P then H(P,P)
> Then the real interdependencies change the behavior from what is expected.

No, they do not change the behaviour of P(P). They just prevent H from
correctly answering the question. If something different happens inside
H that is irrelevant because that is not the behaviour which H is
required to describe.
The fact that H cannot answer the question 'does P(P) when run
independently run halt?' does not change the fact that this is the
correct question, nor does it have any effect on the correct answer,
which is 'yes, it halts'.

The question is fixed as a matter of definition.
The answer to the question is determined by the actual behaviour of P(P).

André

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

On 11/24/21 12:48 AM, olcott wrote:
> On 11/23/2021 10:18 PM, André G. Isaak wrote:
>> On 2021-11-23 21:03, olcott wrote:
>>> On 11/23/2021 9:44 PM, André G. Isaak wrote:
>>>> On 2021-11-23 20:24, olcott wrote:
>>>>> On 11/23/2021 8:22 PM, André G. Isaak wrote:
>>>>>> On 2021-11-23 18:53, olcott wrote:
>>>>>>> On 11/23/2021 7:34 PM, André G. Isaak wrote:
>>>>>
>>>>>> Crucially, the halting function exists *independently* and *prior*
>>>>>> to any Turing Machine which attempts to compute this function. The
>>>>>> halting function is *not* associated with any sort of algorithm;
>>>>>> it is simply a mapping. In other words it is simply a denumerably
>>>>>> infinite list of all possible computations and their halting
>>>>>> status expressed as ordered pairs.
>>>>>>
>>>>>
>>>>>
>>>>> You don't realize it but you are asking a decider to make its
>>>>> decision on the basis of a hypothetical string that does not
>>>>> actually exist.
>>>>
>>>> ???
>>>>
>>>> So now you claim the STRING <P> <P> can't exist? But at the same
>>>> time you claim that your H1 returns the correct answer for this
>>>> allegedly impossible string? How on earth does that work.
>>>>
>>>
>>> int H(ptr x, ptr y) { x(y); }
>>> int H1(ptr x, ptr y) { x(y); int P(ptr x) { H(x, x); }
>>> int P1(ptr x) { H1(x, x); }
>>
>>
>> What does any of this have to do with your ridiculous claim that the
>> string <P> <P> does not actually exist?
>
> If you want the actual behavior of P(P) run independently
> then you have to change P or H into something that they are not
> because they are defined with hardwired inter-dependency.
>

LIE, you don't.

You are still stuck on the idea for the verifier to check out what P(P)
will do he needs to use H to do that, he doesn't, he just runs P(P)
directly to see. As long as P is a Turing Machine (or an equivalent)
that is by definition possible.

The

> You can imagine a P that does not call H(P1,P1)
> That is not the actual P it is only imaginary.

Why can P not call H(P,P)? What stops it.

Actual, how can a P(P) call H(P1,P1), where does it get the description
of P1 instead of P?

There is NO problem in P(P) calling H(P,P).

>
> or you could imaging an H1(P,P) that is not called by P
> That is not the actual H it is only imaginary.

You are loosing it. P, by definition calls H,

>
> When we take the actual H and the actual P then H(P,P)
> Then the real interdependencies change the behavior from what is expected.

It isn't what you EXEPCT. It is what actually happens.

The fact that H can't get the answer right says H fails to get the
answer right, not that their is some need to change the definition.

H will do what it does, it is, by DEFINITION, just an algorithm. P will
do what it does, it is also an algorithm. There is no problem here.

Yes, BY CONSTRUCTION, the answer H gives will not match the behavior of
H^/P, but there is no logical problem here, that just means that H was
incorrect.

The only logical error is that you assume that H must be right. There is
no algorithm for 'Be right', so no logical problem with H being wrong.

It does blow up a lot of your precious ideas of how you THINK logic
should work, but that just shows the problem with your ideas, not with
logic.

André G. Isaak <agisaak@gm.invalid> writes:

> Your obsession with this one particular non-computable function is a
> bit mysterious.

I think it has to do with how hard he finds changing even tiny details.
It's must simpler to deal with halting (in TMs) starting from a "blank
tape" halt decider -- an assumed TM B with this behaviour

B <M> ⊢ qn if M ⊢ oo
B <M> ⊢ qy otherwise.

There's no need to worry about encoding pairs and so on. These
computations are just TMs run with blank tapes.

If such a B existed:

B <B> ⊢ qn if B ⊢ oo
B <B> ⊢ qy otherwise.

I tried, long ago, to suggest this simpler approach, but I think PO
interprets such suggestions as an attempt to bamboozle him -- because he
is bamboozled by such changes.

--
Ben.

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

> André G. Isaak <agisaak@gm.invalid> writes:
>
>> Your obsession with this one particular non-computable function is a
>> bit mysterious.
>
> I think it has to do with how hard he finds changing even tiny details.
> It's must simpler to deal with halting (in TMs) starting from a "blank
> tape" halt decider -- an assumed TM B with this behaviour
>
> B <M> ⊢ qn if M ⊢ oo
> B <M> ⊢ qy otherwise.
>
> There's no need to worry about encoding pairs and so on. These
> computations are just TMs run with blank tapes.
>
> If such a B existed:
>
> B <B> ⊢ qn if B ⊢ oo
> B <B> ⊢ qy otherwise.

Sorry, posted to fast! You need B' that clears the tape then behaves as B
does:

B' <B'> ⊢ B ⊢ qn if B ⊢ oo
B' <B'> ⊢ B ⊢ qy otherwise.

> I tried, long ago, to suggest this simpler approach, but I think PO
> interprets such suggestions as an attempt to bamboozle him -- because he
> is bamboozled by such changes.

--
Ben.

On 11/24/2021 12:27 AM, André G. Isaak wrote:
> On 2021-11-23 22:48, olcott wrote:
>> On 11/23/2021 10:18 PM, André G. Isaak wrote:
>>> On 2021-11-23 21:03, olcott wrote:
>>>> On 11/23/2021 9:44 PM, André G. Isaak wrote:
>>>>> On 2021-11-23 20:24, olcott wrote:
>>>>>> On 11/23/2021 8:22 PM, André G. Isaak wrote:
>>>>>>> On 2021-11-23 18:53, olcott wrote:
>>>>>>>> On 11/23/2021 7:34 PM, André G. Isaak wrote:
>>>>>>
>>>>>>> Crucially, the halting function exists *independently* and
>>>>>>> *prior* to any Turing Machine which attempts to compute this
>>>>>>> function. The halting function is *not* associated with any sort
>>>>>>> of algorithm; it is simply a mapping. In other words it is simply
>>>>>>> a denumerably infinite list of all possible computations and
>>>>>>> their halting status expressed as ordered pairs.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> You don't realize it but you are asking a decider to make its
>>>>>> decision on the basis of a hypothetical string that does not
>>>>>> actually exist.
>>>>>
>>>>> ???
>>>>>
>>>>> So now you claim the STRING <P> <P> can't exist? But at the same
>>>>> time you claim that your H1 returns the correct answer for this
>>>>> allegedly impossible string? How on earth does that work.
>>>>>
>>>>
>>>> int H(ptr x, ptr y) { x(y); }
>>>> int H1(ptr x, ptr y) { x(y); int P(ptr x) { H(x, x); }
>>>> int P1(ptr x) { H1(x, x); }
>>>
>>>
>>> What does any of this have to do with your ridiculous claim that the
>>> string <P> <P> does not actually exist?
>>
>> If you want the actual behavior of P(P) run independently
>> then you have to change P or H into something that they are not
>> because they are defined with hardwired inter-dependency.
>
> If you want the actual behaviour of P(P) run independently, you simply
> run P(P) independently.
>

So in other words H must report on the behavior of a finite string that
is not is input.

> I think what you mean to say is if you want H to give you the correct
> answer about the actual behaviour of P(P) run independently, which it
> can't. The interdependency prevents this.
>

It is incorrect to think of H having the hypothetical input where P does
not call H.All deciders must have finite string inputs. Because P foes
call this same H changing P so that it does not call this same H is
incorrect.

It is equally incorrect to have H report on the behavior of P as if H
was H1 where P does not call H1.

> But that does not change the fact that the computation P(P) halts, and

The fact there there are no cats in the kitchen does not have one damn
thing to do with dogs in the living room. I can't imagine how people can
so persistently make this strawman error even after being warned dozens
of times.

#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);
}

Combinations of (H,P) having pathological self-reference (PSR)
H(P,P) simulates or executes its input and aborts or does
not abort its input and P(P) calls this same H(P,P) with itself.

for all Hn(Pn,Pn) in the above PSR set Pn never reaches its final
instruction.

> that this therefore is the only correct answer to the question which a
> halt decider is required to answer.

That is not the freaking way that deciders work.

If H(P,P) reports on the behavior of H1(P,P) or H(P1,P1) it freaking
answered the wrong freaking question.

Those are the only pair of combinations that show P(P) as an independent
computation and they are both answers to the wrong question.

The one key verified fact that everyone simply assumes away even though
it is a verified fact is that there are elements of the PSR set such
that the input to Hn(Pn,Pn) never reaches its final state and Pn(Pn)
does reach its final state in this exact same sequence of configurations.

People assume that the placement in the execution trace can't make a
difference and yet it is a verified fact that this placement does make a
difference. The one way dependency relationship that Pn(Pn) has on
Hn(Pn,Pn) causes the outer Pn to behave differently than the inner Pn.

Simply assuming this away is flat out dishonest.

> It can't get that answer, but that's
> the whole point. Your H cannot correctly decide P(P) just as Linz
> claims. You can't claim it gets P(P) right by attempting to change the
> question.
>
>> You can imagine a P that does not call H(P1,P1)
>> That is not the actual P it is only imaginary.
>>
>> or you could imaging an H1(P,P) that is not called by P
>> That is not the actual H it is only imaginary.
>>
>> When we take the actual H and the actual P then H(P,P)
>> Then the real interdependencies change the behavior from what is
>> expected.
>
> No, they do not change the behaviour of P(P). They just prevent H from
> correctly answering the question. If something different happens inside
> H that is irrelevant because that is not the behaviour which H is
> required to describe.
> The fact that H cannot answer the question 'does P(P) when run
> independently run halt?' does not change the fact that this is the
> correct question, nor does it have any effect on the correct answer,
> which is 'yes, it halts'.
>
> The question is fixed as a matter of definition.
> The answer to the question is determined by the actual behaviour of P(P).
>
> André
>

--
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/24/2021 8:52 AM, Ben Bacarisse wrote:
> André G. Isaak <agisaak@gm.invalid> writes:
>
>> Your obsession with this one particular non-computable function is a
>> bit mysterious.
>
> I think it has to do with how hard he finds changing even tiny details.
> It's must simpler to deal with halting (in TMs) starting from a "blank
> tape" halt decider -- an assumed TM B with this behaviour
>
> B <M> ⊢ qn if M ⊢ oo
> B <M> ⊢ qy otherwise.
>
> There's no need to worry about encoding pairs and so on. These
> computations are just TMs run with blank tapes.
>

B can't have a blank tape iy must have <M> on its tape,
<M> can have a blank tape.

> If such a B existed:
>
> B <B> ⊢ qn if B ⊢ oo
> B <B> ⊢ qy otherwise.
>

<B> requires that its tape not be blank.
type mismatch error.

> I tried, long ago, to suggest this simpler approach, but I think PO
> interprets such suggestions as an attempt to bamboozle him -- because he
> is bamboozled by such changes.
>

--
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/24/2021 8:55 AM, Ben Bacarisse wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> André G. Isaak <agisaak@gm.invalid> writes:
>>
>>> Your obsession with this one particular non-computable function is a
>>> bit mysterious.
>>
>> I think it has to do with how hard he finds changing even tiny details.
>> It's must simpler to deal with halting (in TMs) starting from a "blank
>> tape" halt decider -- an assumed TM B with this behaviour
>>
>> B <M> ⊢ qn if M ⊢ oo
>> B <M> ⊢ qy otherwise.
>>
>> There's no need to worry about encoding pairs and so on. These
>> computations are just TMs run with blank tapes.
>>
>> If such a B existed:
>>
>> B <B> ⊢ qn if B ⊢ oo
>> B <B> ⊢ qy otherwise.
>

<B> requires an input

> Sorry, posted to fast! You need B' that clears the tape then behaves as B
> does:
>
> B' <B'> ⊢ B ⊢ qn if B ⊢ oo
> B' <B'> ⊢ B ⊢ qy otherwise.
>

Add meaningful names to provide cognitive leverage
H <P> ⊢ qn if P ⊢ oo
H <P> ⊢ qy otherwise.

H has <P> on its tape.
<P> has an empty tape.

To keep things simple there are only two types of P
(a) Immediately halts (b) immediately loops

To the best of my knowledge what you are asking is which
state does H transition to when the first thing that H
does is erase itself from its tape.

An empty input is not an input that loops.

>> I tried, long ago, to suggest this simpler approach, but I think PO
>> interprets such suggestions as an attempt to bamboozle him -- because he
>> is bamboozled by such changes.
>

--
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-24 08:02, olcott wrote:
> On 11/24/2021 12:27 AM, André G. Isaak wrote:
>> On 2021-11-23 22:48, olcott wrote:
>>> On 11/23/2021 10:18 PM, André G. Isaak wrote:
>>>> On 2021-11-23 21:03, olcott wrote:
>>>>> On 11/23/2021 9:44 PM, André G. Isaak wrote:
>>>>>> On 2021-11-23 20:24, olcott wrote:
>>>>>>> On 11/23/2021 8:22 PM, André G. Isaak wrote:
>>>>>>>> On 2021-11-23 18:53, olcott wrote:
>>>>>>>>> On 11/23/2021 7:34 PM, André G. Isaak wrote:
>>>>>>>
>>>>>>>> Crucially, the halting function exists *independently* and
>>>>>>>> *prior* to any Turing Machine which attempts to compute this
>>>>>>>> function. The halting function is *not* associated with any sort
>>>>>>>> of algorithm; it is simply a mapping. In other words it is
>>>>>>>> simply a denumerably infinite list of all possible computations
>>>>>>>> and their halting status expressed as ordered pairs.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> You don't realize it but you are asking a decider to make its
>>>>>>> decision on the basis of a hypothetical string that does not
>>>>>>> actually exist.
>>>>>>
>>>>>> ???
>>>>>>
>>>>>> So now you claim the STRING <P> <P> can't exist? But at the same
>>>>>> time you claim that your H1 returns the correct answer for this
>>>>>> allegedly impossible string? How on earth does that work.
>>>>>>
>>>>>
>>>>> int H(ptr x, ptr y) { x(y); }
>>>>> int H1(ptr x, ptr y) { x(y); int P(ptr x) { H(x, x); }
>>>>> int P1(ptr x) { H1(x, x); }
>>>>
>>>>
>>>> What does any of this have to do with your ridiculous claim that the
>>>> string <P> <P> does not actually exist?
>>>
>>> If you want the actual behavior of P(P) run independently
>>> then you have to change P or H into something that they are not
>>> because they are defined with hardwired inter-dependency.
>>
>> If you want the actual behaviour of P(P) run independently, you simply
>> run P(P) independently.
>>
>
> So in other words H must report on the behavior of a finite string that
> is not is input.

H doesn't report on the behaviour of finite strings at all. It reports
on the behaviour of computations.

P(P) is a computation which halts.

Your H needs to be able to report that P(P) halts (or any other
arbitrary computation).

Determining exactly how that particular computation must be encoded as a
finite string so it can be passed as an input to H is part of your job
when designing H.

Maybe you don't grasp this. Consider two UTMs, X and Y (and by UTM I
mean actual UTMs). Both of these should be able to emulate P(P) if we
give them two copies of a string which describes the Turing Machine P.

But the strings we pass to X and the string we pass to Y are *not*
necessarily the same string. X and Y may use different alphabets and may
use different encoding schemes. To constitute a UTM, it must be the
case, though, that it is possible to represent every possible
computation as a string that can be passed to that UTM.

If you've designed an H such that there is no possible way to represent
the independent computation P(P) as a string which can be passed to H as
an input, then there is something wrong with your design.

>> I think what you mean to say is if you want H to give you the correct
>> answer about the actual behaviour of P(P) run independently, which it
>> can't. The interdependency prevents this.
>>
>
> It is incorrect to think of H having the hypothetical input where P does
> not call H.All deciders must have finite string inputs. Because P foes

Where did I (or anyone) mention a P that does not simulate/call H?

H is required to describe the halting behaviour of the independent
computation P(P). That means it must describe how P(P) behaves when
called directly from main rather than from within your halt decider.

> call this same H changing P so that it does not call this same H is
> incorrect.
>
> It is equally incorrect to have H report on the behavior of P as if H
> was H1 where P does not call H1.
>
>> But that does not change the fact that the computation P(P) halts, and
>
> The fact there there are no cats in the kitchen does not have one damn
> thing to do with dogs in the living room. I can't imagine how people can
> so persistently make this strawman error even after being warned dozens
> of times.
>
> #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);
> }
>
> Combinations of (H,P) having pathological self-reference (PSR)
>   H(P,P) simulates or executes its input and aborts or does
>   not abort its input and P(P) calls this same H(P,P) with itself.
>
> for all Hn(Pn,Pn) in the above PSR set Pn never reaches its final
> instruction.
>
>
>> that this therefore is the only correct answer to the question which a
>> halt decider is required to answer.
>
> That is not the freaking way that deciders work.

A decider accepts or rejects all possible inputs based on some criteria
determined by the problem at hand.

For the halting problem, the criterion is that the decider must accept
all and only those independent computations which HALT.

> If H(P,P) reports on the behavior of H1(P,P) or H(P1,P1) it freaking
> answered the wrong freaking question.
>
> Those are the only pair of combinations that show P(P) as an independent
> computation and they are both answers to the wrong question.

NEITHER of those show P(P) as an independent computation.

H(P,P) must report on the behaviour of P(P). That's the *only* behaviour
it is being asked about.

>
> The one key verified fact that everyone simply assumes away even though
> it is a verified fact is that there are elements of the PSR set such
> that the input to Hn(Pn,Pn) never reaches its final state and Pn(Pn)
> does reach its final state in this exact same sequence of configurations.
>
> People assume that the placement in the execution trace can't make a
> difference and yet it is a verified fact that this placement does make a
> difference. The one way dependency relationship that Pn(Pn) has on
> Hn(Pn,Pn) causes the outer Pn to behave differently than the inner Pn.
>
> Simply assuming this away is flat out dishonest.

None of this is relevant (or even coherent). H(P, P) by the definition
of the problem must report the behaviour of the independent computation
P(P). Whether the "placement in the execution trace can make a
difference" has no bearing on the behaviour of P(P). It might have some
bearing on the behaviour of the simulation of P(P) inside of H, but
that's not what the halt decider is being asked about.

The question which a halt decider must answer is well defined. If your
decider can't answer this correctly that does *not* change what the
question is.

André

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

On 11/24/21 10:02 AM, olcott wrote:
> On 11/24/2021 12:27 AM, André G. Isaak wrote:
>> On 2021-11-23 22:48, olcott wrote:
>>> On 11/23/2021 10:18 PM, André G. Isaak wrote:
>>>> On 2021-11-23 21:03, olcott wrote:
>>>>> On 11/23/2021 9:44 PM, André G. Isaak wrote:
>>>>>> On 2021-11-23 20:24, olcott wrote:
>>>>>>> On 11/23/2021 8:22 PM, André G. Isaak wrote:
>>>>>>>> On 2021-11-23 18:53, olcott wrote:
>>>>>>>>> On 11/23/2021 7:34 PM, André G. Isaak wrote:
>>>>>>>
>>>>>>>> Crucially, the halting function exists *independently* and
>>>>>>>> *prior* to any Turing Machine which attempts to compute this
>>>>>>>> function. The halting function is *not* associated with any sort
>>>>>>>> of algorithm; it is simply a mapping. In other words it is
>>>>>>>> simply a denumerably infinite list of all possible computations
>>>>>>>> and their halting status expressed as ordered pairs.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> You don't realize it but you are asking a decider to make its
>>>>>>> decision on the basis of a hypothetical string that does not
>>>>>>> actually exist.
>>>>>>
>>>>>> ???
>>>>>>
>>>>>> So now you claim the STRING <P> <P> can't exist? But at the same
>>>>>> time you claim that your H1 returns the correct answer for this
>>>>>> allegedly impossible string? How on earth does that work.
>>>>>>
>>>>>
>>>>> int H(ptr x, ptr y) { x(y); }
>>>>> int H1(ptr x, ptr y) { x(y); int P(ptr x) { H(x, x); }
>>>>> int P1(ptr x) { H1(x, x); }
>>>>
>>>>
>>>> What does any of this have to do with your ridiculous claim that the
>>>> string <P> <P> does not actually exist?
>>>
>>> If you want the actual behavior of P(P) run independently
>>> then you have to change P or H into something that they are not
>>> because they are defined with hardwired inter-dependency.
>>
>> If you want the actual behaviour of P(P) run independently, you simply
>> run P(P) independently.
>>
>
> So in other words H must report on the behavior of a finite string that
> is not is input.

No, it must report the behavior of the computation that the finite
string it was give represents.

STRINGS don't have behavior. They may have MEANING.

For the case of Representations of Computations, we DO have a special
machine that we can use to convert a finite string into behavior, and
that special machine is called a UTM. A UTM is DEFINED as a Turing
Machine that will exactly reproduce the behavior of the Computations
that is provided as its input.

H is NOT a UTM, or even an 'equivalent' if it aborts its simulation
before that simulation reaches its final halting state. PERIOD (by
DEFINITION).

And H must report the ACTUAL behavior of the Computation the input
represents, or the behavior of an ACTUAL UTM if given the same input as
H was given.

What is most definitely NOT the meaning is the behavior of an aborted
simulation inside of H. That does NOT give the right answer.

>
>> I think what you mean to say is if you want H to give you the correct
>> answer about the actual behaviour of P(P) run independently, which it
>> can't. The interdependency prevents this.
>>
>
> It is incorrect to think of H having the hypothetical input where P does
> not call H.All deciders must have finite string inputs. Because P foes
> call this same H changing P so that it does not call this same H is
> incorrect.
>

The input is NOT hypothetical. If we assume that your H exists, then you
have provided the code for a P, and we can then compile this P and H
together and get an x86 program that contains all of P, H, and
everything that H calls, and this x86 assembly code is PRECISELY the
input we can give to H to ask it the question.

The problem is H doesn't know how to handle this case correct, so H is
proven to NOT be a counter to the Linz Proof.

> It is equally incorrect to have H report on the behavior of P as if H
> was H1 where P does not call H1.

No, H needs to report the behavior of what its input would do when run
as an independent computation. If H1 just happens to act like a UTM for
this input, then if H could determine what H1 would do that would be ok,
BECAUSE the definition of what it needs to report on is what the input
would do as an independent computation, which CAN be also determined by
the results of giving this input to a UTM.

What is WRONG, is looking at the INCOMPLETE/INCORRECT simulation that H
does of its input. That is shown to NOT be the same as the behavior the
input defines as a representation. PERIOD.

The fact that H can't do that, is not a logical problem, it just means
that this design of a Halt Decider can't get this form of machine
correctly. (and Linz shows that NO design of a Halt Decider can get the
answer correctly for a machine built this way from it).

>
>> But that does not change the fact that the computation P(P) halts, and
>
> The fact there there are no cats in the kitchen does not have one damn
> thing to do with dogs in the living room. I can't imagine how people can
> so persistently make this strawman error even after being warned dozens
> of times.

And the fact that H doesn't see its INCORRECT/PARTIAL simulation of P(P)
doesn't mean anything about the Halting behavior of the ACTUAL operation
of the computation P(P).

>
> #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);
> }
>
> Combinations of (H,P) having pathological self-reference (PSR)
>   H(P,P) simulates or executes its input and aborts or does
>   not abort its input and P(P) calls this same H(P,P) with itself.
>
> for all Hn(Pn,Pn) in the above PSR set Pn never reaches its final
> instruction.

LIE.

For ALL Hn(Pn,Pn) where Hn(Pn,Pn) returns 0 (because it aborted its
simulation/execution), it is shown taht Pn(Pn) will Halt.

Yes, Hn does not reach that point in its simulation, but that is because
it aborted it before it got there.

Your PSR set appears to be about POOP, not Halting.

>
>
>> that this therefore is the only correct answer to the question which a
>> halt decider is required to answer.
>
> That is not the freaking way that deciders work.

It IS.

The RIGHT answer for a decider is what the right answer for that problem
would be.

The question "Does P(P) Halt?" which is supposedly (by your claim that H
is a Halt Decider) is what the call H(P,P) is supposed to mean.

The fact that when H(P,P) returns 0, we have that P(P) does halt, then H
is shown to be WRONG.

>
> If H(P,P) reports on the behavior of H1(P,P) or H(P1,P1) it freaking
> answered the wrong freaking question.

H(P,P) is suppose to report the behavior of P(P), THAT is the definition
of a Halt Decider.

>
> Those are the only pair of combinations that show P(P) as an independent
> computation and they are both answers to the wrong question.

LIE.

P(P) shows the behavior if itself. THAT is what you need to match.

If some other computations just happen to match this, then H could get
the correct answer from those, but as you point out, it can't get those
either.

>
>
> The one key verified fact that everyone simply assumes away even though
> it is a verified fact is that there are elements of the PSR set such
> that the input to Hn(Pn,Pn) never reaches its final state and Pn(Pn)
> does reach its final state in this exact same sequence of configurations.
>
> People assume that the placement in the execution trace can't make a
> difference and yet it is a verified fact that this placement does make a
> difference. The one way dependency relationship that Pn(Pn) has on
> Hn(Pn,Pn) causes the outer Pn to behave differently than the inner Pn.

Because, to be a Computation, it CAN'T. The Computation H(p,i) can ONLY
depend on the values of p and i, and NOT anything else, like the fact
that H is geing called by another copy of p.

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

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> André G. Isaak <agisaak@gm.invalid> writes:
>>
>>> Your obsession with this one particular non-computable function is a
>>> bit mysterious.
>>
>> I think it has to do with how hard he finds changing even tiny details.
>> It's must simpler to deal with halting (in TMs) starting from a "blank
>> tape" halt decider -- an assumed TM B with this behaviour
>>
>> B <M> ⊢ qn if M ⊢ oo
>> B <M> ⊢ qy otherwise.
>>
>> There's no need to worry about encoding pairs and so on. These
>> computations are just TMs run with blank tapes.
>>
>> If such a B existed:
>>
>> B <B> ⊢ qn if B ⊢ oo
>> B <B> ⊢ qy otherwise.
>
> Sorry, posted to fast!

You're telling me! Scratch this. Let's just say getting the details
right are left as an exercise to for the reader!

--
Ben.

On 11/24/2021 9:50 AM, André G. Isaak wrote:
> On 2021-11-24 08:02, olcott wrote:
>> On 11/24/2021 12:27 AM, André G. Isaak wrote:
>>> On 2021-11-23 22:48, olcott wrote:
>>>> On 11/23/2021 10:18 PM, André G. Isaak wrote:
>>>>> On 2021-11-23 21:03, olcott wrote:
>>>>>> On 11/23/2021 9:44 PM, André G. Isaak wrote:
>>>>>>> On 2021-11-23 20:24, olcott wrote:
>>>>>>>> On 11/23/2021 8:22 PM, André G. Isaak wrote:
>>>>>>>>> On 2021-11-23 18:53, olcott wrote:
>>>>>>>>>> On 11/23/2021 7:34 PM, André G. Isaak wrote:
>>>>>>>>
>>>>>>>>> Crucially, the halting function exists *independently* and
>>>>>>>>> *prior* to any Turing Machine which attempts to compute this
>>>>>>>>> function. The halting function is *not* associated with any
>>>>>>>>> sort of algorithm; it is simply a mapping. In other words it is
>>>>>>>>> simply a denumerably infinite list of all possible computations
>>>>>>>>> and their halting status expressed as ordered pairs.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> You don't realize it but you are asking a decider to make its
>>>>>>>> decision on the basis of a hypothetical string that does not
>>>>>>>> actually exist.
>>>>>>>
>>>>>>> ???
>>>>>>>
>>>>>>> So now you claim the STRING <P> <P> can't exist? But at the same
>>>>>>> time you claim that your H1 returns the correct answer for this
>>>>>>> allegedly impossible string? How on earth does that work.
>>>>>>>
>>>>>>
>>>>>> int H(ptr x, ptr y) { x(y); }
>>>>>> int H1(ptr x, ptr y) { x(y); int P(ptr x) { H(x, x); }
>>>>>> int P1(ptr x) { H1(x, x); }
>>>>>
>>>>>
>>>>> What does any of this have to do with your ridiculous claim that
>>>>> the string <P> <P> does not actually exist?
>>>>
>>>> If you want the actual behavior of P(P) run independently
>>>> then you have to change P or H into something that they are not
>>>> because they are defined with hardwired inter-dependency.
>>>
>>> If you want the actual behaviour of P(P) run independently, you
>>> simply run P(P) independently.
>>>
>>
>> So in other words H must report on the behavior of a finite string
>> that is not is input.
>
> H doesn't report on the behaviour of finite strings at all. It reports
> on the behaviour of computations.
>
> P(P) is a computation which halts.
>
> Your H needs to be able to report that P(P) halts (or any other
> arbitrary computation).
>
> Determining exactly how that particular computation must be encoded as a
> finite string so it can be passed as an input to H is part of your job
> when designing H.
>
> Maybe you don't grasp this. Consider two UTMs, X and Y (and by UTM I
> mean actual UTMs). Both of these should be able to emulate P(P) if we
> give them two copies of a string which describes the Turing Machine P.
>
> But the strings we pass to X and the string we pass to Y are *not*
> necessarily the same string. X and Y may use different alphabets and may
> use different encoding schemes. To constitute a UTM, it must be the
> case, though, that it is possible to represent every possible
> computation as a string that can be passed to that UTM.
>
> If you've designed an H such that there is no possible way to represent
> the independent computation P(P) as a string which can be passed to H as
> an input, then there is something wrong with your design.
>
>>> I think what you mean to say is if you want H to give you the correct
>>> answer about the actual behaviour of P(P) run independently, which it
>>> can't. The interdependency prevents this.
>>>
>>
>> It is incorrect to think of H having the hypothetical input where P
>> does not call H.All deciders must have finite string inputs. Because P
>> foes
>
> Where did I (or anyone) mention a P that does not simulate/call H?
>
> H is required to describe the halting behaviour of the independent
> computation P(P). That means it must describe how P(P) behaves when
> called directly from main rather than from within your halt decider.
>
>> call this same H changing P so that it does not call this same H is
>> incorrect.
>>
>> It is equally incorrect to have H report on the behavior of P as if H
>> was H1 where P does not call H1.
>>
>>> But that does not change the fact that the computation P(P) halts, and
>>
>> The fact there there are no cats in the kitchen does not have one damn
>> thing to do with dogs in the living room. I can't imagine how people
>> can so persistently make this strawman error even after being warned
>> dozens of times.
>>
>> #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);
>> }
>>
>> Combinations of (H,P) having pathological self-reference (PSR)
>>    H(P,P) simulates or executes its input and aborts or does
>>    not abort its input and P(P) calls this same H(P,P) with itself.
>>
>> for all Hn(Pn,Pn) in the above PSR set Pn never reaches its final
>> instruction.
>>
>>
>>> that this therefore is the only correct answer to the question which
>>> a halt decider is required to answer.
>>
>> That is not the freaking way that deciders work.
>
> A decider accepts or rejects all possible inputs based on some criteria
> determined by the problem at hand.
>
> For the halting problem, the criterion is that the decider must accept
> all and only those independent computations which HALT.
>
>
>> If H(P,P) reports on the behavior of H1(P,P) or H(P1,P1) it freaking
>> answered the wrong freaking question.
>>
>> Those are the only pair of combinations that show P(P) as an
>> independent computation and they are both answers to the wrong question.
>
> NEITHER of those show P(P) as an independent computation.
>
> H(P,P) must report on the behaviour of P(P). That's the *only* behaviour
> it is being asked about.
>
>>
>> The one key verified fact that everyone simply assumes away even
>> though it is a verified fact is that there are elements of the PSR set
>> such that the input to Hn(Pn,Pn) never reaches its final state and
>> Pn(Pn) does reach its final state in this exact same sequence of
>> configurations.
>>
>> People assume that the placement in the execution trace can't make a
>> difference and yet it is a verified fact that this placement does make
>> a difference. The one way dependency relationship that Pn(Pn) has on
>> Hn(Pn,Pn) causes the outer Pn to behave differently than the inner Pn.
>>
>> Simply assuming this away is flat out dishonest.
>
> None of this is relevant (or even coherent). H(P, P) by the definition
> of the problem must report the behaviour of the independent computation
> P(P). Whether the "placement in the execution trace can make a
> difference" has no bearing on the behaviour of P(P). It might have some
> bearing on the behaviour of the simulation of P(P) inside of H, but
> that's not what the halt decider is being asked about.

The sequence of 1 to N configurations specified by the input to H(X, Y)
cannot be correctly construed as anything other than the sequence of 1
to N steps of the (direct execution, x86 emulation or UTM simulation of
this input by H.

--
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-24 21:54, olcott wrote:

> The sequence of 1 to N configurations specified by the input to H(X, Y)
> cannot be correctly construed as anything other than the sequence of 1
> to N steps of the (direct execution, x86 emulation or UTM simulation of
> this input by H.

You've now made this same statement in response to three different
posts. In no case does it appear to relate to anything you are
responding to. Perhaps you'd care to explain why you think this
statement is relevant or meaningful?

André

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

On 11/24/2021 9:50 AM, André G. Isaak wrote:
> On 2021-11-24 08:02, olcott wrote:
>> People assume that the placement in the execution trace can't make a
>> difference and yet it is a verified fact that this placement does make
>> a difference. The one way dependency relationship that Pn(Pn) has on
>> Hn(Pn,Pn) causes the outer Pn to behave differently than the inner Pn.
>>
>> Simply assuming this away is flat out dishonest.
>

> H(P, P) by the definition of the problem must report
> the behaviour of the independent computation P(P).

All that the halt decider gets is a pair of input strings specifying a
machine description and another finite string.

The correct sequence of 1 to N configurations specified by that input
pair can only be derived by 1 to N steps of (direct execution, x86
emulation or UTM simulation) of this input by H.

> Whether the "placement in the execution trace can make a
> difference" has no bearing on the behaviour of P(P). It might have some
> bearing on the behaviour of the simulation of P(P) inside of H, but
> that's not what the halt decider is being asked about.
>
> The question which a halt decider must answer is well defined. If your
> decider can't answer this correctly that does *not* change what the
> question is.
>
> André
>
>

--
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/24/21 11:54 PM, olcott wrote:
> On 11/24/2021 9:50 AM, André G. Isaak wrote:
>> On 2021-11-24 08:02, olcott wrote:
>>> On 11/24/2021 12:27 AM, André G. Isaak wrote:
>>>> On 2021-11-23 22:48, olcott wrote:
>>>>> On 11/23/2021 10:18 PM, André G. Isaak wrote:
>>>>>> On 2021-11-23 21:03, olcott wrote:
>>>>>>> On 11/23/2021 9:44 PM, André G. Isaak wrote:
>>>>>>>> On 2021-11-23 20:24, olcott wrote:
>>>>>>>>> On 11/23/2021 8:22 PM, André G. Isaak wrote:
>>>>>>>>>> On 2021-11-23 18:53, olcott wrote:
>>>>>>>>>>> On 11/23/2021 7:34 PM, André G. Isaak wrote:
>>>>>>>>>
>>>>>>>>>> Crucially, the halting function exists *independently* and
>>>>>>>>>> *prior* to any Turing Machine which attempts to compute this
>>>>>>>>>> function. The halting function is *not* associated with any
>>>>>>>>>> sort of algorithm; it is simply a mapping. In other words it
>>>>>>>>>> is simply a denumerably infinite list of all possible
>>>>>>>>>> computations and their halting status expressed as ordered pairs.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You don't realize it but you are asking a decider to make its
>>>>>>>>> decision on the basis of a hypothetical string that does not
>>>>>>>>> actually exist.
>>>>>>>>
>>>>>>>> ???
>>>>>>>>
>>>>>>>> So now you claim the STRING <P> <P> can't exist? But at the same
>>>>>>>> time you claim that your H1 returns the correct answer for this
>>>>>>>> allegedly impossible string? How on earth does that work.
>>>>>>>>
>>>>>>>
>>>>>>> int H(ptr x, ptr y) { x(y); }
>>>>>>> int H1(ptr x, ptr y) { x(y); int P(ptr x) { H(x, x); }
>>>>>>> int P1(ptr x) { H1(x, x); }
>>>>>>
>>>>>>
>>>>>> What does any of this have to do with your ridiculous claim that
>>>>>> the string <P> <P> does not actually exist?
>>>>>
>>>>> If you want the actual behavior of P(P) run independently
>>>>> then you have to change P or H into something that they are not
>>>>> because they are defined with hardwired inter-dependency.
>>>>
>>>> If you want the actual behaviour of P(P) run independently, you
>>>> simply run P(P) independently.
>>>>
>>>
>>> So in other words H must report on the behavior of a finite string
>>> that is not is input.
>>
>> H doesn't report on the behaviour of finite strings at all. It reports
>> on the behaviour of computations.
>>
>> P(P) is a computation which halts.
>>
>> Your H needs to be able to report that P(P) halts (or any other
>> arbitrary computation).
>>
>> Determining exactly how that particular computation must be encoded as
>> a finite string so it can be passed as an input to H is part of your
>> job when designing H.
>>
>> Maybe you don't grasp this. Consider two UTMs, X and Y (and by UTM I
>> mean actual UTMs). Both of these should be able to emulate P(P) if we
>> give them two copies of a string which describes the Turing Machine P.
>>
>> But the strings we pass to X and the string we pass to Y are *not*
>> necessarily the same string. X and Y may use different alphabets and
>> may use different encoding schemes. To constitute a UTM, it must be
>> the case, though, that it is possible to represent every possible
>> computation as a string that can be passed to that UTM.
>>
>> If you've designed an H such that there is no possible way to
>> represent the independent computation P(P) as a string which can be
>> passed to H as an input, then there is something wrong with your design.
>>
>>>> I think what you mean to say is if you want H to give you the
>>>> correct answer about the actual behaviour of P(P) run independently,
>>>> which it can't. The interdependency prevents this.
>>>>
>>>
>>> It is incorrect to think of H having the hypothetical input where P
>>> does not call H.All deciders must have finite string inputs. Because
>>> P foes
>>
>> Where did I (or anyone) mention a P that does not simulate/call H?
>>
>> H is required to describe the halting behaviour of the independent
>> computation P(P). That means it must describe how P(P) behaves when
>> called directly from main rather than from within your halt decider.
>>
>>> call this same H changing P so that it does not call this same H is
>>> incorrect.
>>>
>>> It is equally incorrect to have H report on the behavior of P as if H
>>> was H1 where P does not call H1.
>>>
>>>> But that does not change the fact that the computation P(P) halts, and
>>>
>>> The fact there there are no cats in the kitchen does not have one
>>> damn thing to do with dogs in the living room. I can't imagine how
>>> people can so persistently make this strawman error even after being
>>> warned dozens of times.
>>>
>>> #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);
>>> }
>>>
>>> Combinations of (H,P) having pathological self-reference (PSR)
>>>    H(P,P) simulates or executes its input and aborts or does
>>>    not abort its input and P(P) calls this same H(P,P) with itself.
>>>
>>> for all Hn(Pn,Pn) in the above PSR set Pn never reaches its final
>>> instruction.
>>>
>>>
>>>> that this therefore is the only correct answer to the question which
>>>> a halt decider is required to answer.
>>>
>>> That is not the freaking way that deciders work.
>>
>> A decider accepts or rejects all possible inputs based on some
>> criteria determined by the problem at hand.
>>
>> For the halting problem, the criterion is that the decider must accept
>> all and only those independent computations which HALT.
>>
>>
>>> If H(P,P) reports on the behavior of H1(P,P) or H(P1,P1) it freaking
>>> answered the wrong freaking question.
>>>
>>> Those are the only pair of combinations that show P(P) as an
>>> independent computation and they are both answers to the wrong question.
>>
>> NEITHER of those show P(P) as an independent computation.
>>
>> H(P,P) must report on the behaviour of P(P). That's the *only*
>> behaviour it is being asked about.
>>
>>>
>>> The one key verified fact that everyone simply assumes away even
>>> though it is a verified fact is that there are elements of the PSR
>>> set such that the input to Hn(Pn,Pn) never reaches its final state
>>> and Pn(Pn) does reach its final state in this exact same sequence of
>>> configurations.
>>>
>>> People assume that the placement in the execution trace can't make a
>>> difference and yet it is a verified fact that this placement does
>>> make a difference. The one way dependency relationship that Pn(Pn)
>>> has on Hn(Pn,Pn) causes the outer Pn to behave differently than the
>>> inner Pn.
>>>
>>> Simply assuming this away is flat out dishonest.
>>
>> None of this is relevant (or even coherent). H(P, P) by the definition
>> of the problem must report the behaviour of the independent
>> computation P(P). Whether the "placement in the execution trace can
>> make a difference" has no bearing on the behaviour of P(P). It might
>> have some bearing on the behaviour of the simulation of P(P) inside of
>> H, but that's not what the halt decider is being asked about.
>
> The sequence of 1 to N configurations specified by the input to H(X, Y)
> cannot be correctly construed as anything other than the sequence of 1
> to N steps of the (direct execution, x86 emulation or UTM simulation of
> this input by H.
>

On 11/25/21 1:04 AM, olcott wrote:
> On 11/24/2021 9:50 AM, André G. Isaak wrote:
>> On 2021-11-24 08:02, olcott wrote:
>>> People assume that the placement in the execution trace can't make a
>>> difference and yet it is a verified fact that this placement does
>>> make a difference. The one way dependency relationship that Pn(Pn)
>>> has on Hn(Pn,Pn) causes the outer Pn to behave differently than the
>>> inner Pn.
>>>
>>> Simply assuming this away is flat out dishonest.
>>
>
> > H(P, P) by the definition of the problem must report
> > the behaviour of the independent computation P(P).
>
> All that the halt decider gets is a pair of input strings specifying a
> machine description and another finite string.
>
> The correct sequence of 1 to N configurations specified by that input
> pair can only be derived by 1 to N steps of (direct execution, x86
> emulation or UTM simulation) of this input by H.
>

So.

You say this like it means something.

An only N step simulation that doesn't reach a halting state says very
little about the behavior of the machine it is simulating, especially
when the simulation isn't accurate as it converts call to H to calls to
the the decided machine, even though this H won't necessarily execute
the full machine it is given.

You are using Unsound logic, perhaps because you have become unsound
yourself.

>
>> Whether the "placement in the execution trace can make a difference"
>> has no bearing on the behaviour of P(P). It might have some bearing on
>> the behaviour of the simulation of P(P) inside of H, but that's not
>> what the halt decider is being asked about.
>>
>> The question which a halt decider must answer is well defined. If your
>> decider can't answer this correctly that does *not* change what the
>> question is.
>>
>> André
>>
>>
>
>