Re: On Strachey [ How nuts is that? ]

[olcott]

On 5/7/2022 5:47 PM, Ben wrote:
> olcott <polc...@gmail.com> writes:
>
>> On 5/6/2022 8:07 PM, Ben wrote:
>>> olcott <polc...@gmail.com> writes:
>>>
>>>> On 5/6/2022 7:11 PM, Ben wrote:
>>>
>>>>> The halting theorem follows, trivially, from lots of simpler theorems,
>>>>> none of which have you bothered to read. In Linz, the theorem is
>>>>> presented as a corollary of a simpler theorem in chapter 11.
>>>>
>>>> 11.3, 11.4, and 11.5. I will look at them.
>>> Goodness! A good move. Why the change of heart?
>>
>> There is enough progress now that I don't have to have an absolutely
>> single-minded focus.
>
> Progress?
>
>> THIS IS AN EASILY VERIFIABLE FACT:
>> Both H() and H1() take the machine code of P as input parameters and
>> correctly compute the mapping from this input to an accept ore reject
>> state on the basis of the actual behavior that these inputs actually
>> specify.
>
> But H does not decide the halting of P(P).


int sum(int N , int M)
{
return (N + M);
}

It is not supposed to in the same way that sum(3,4) is not supposed to
provide the sum of (5,7).

Why is this so difficult for you?

You know that if anyone insisted that sum(3,4) must return the value of
sum(5,7) that they are wrong.

Why is it so hard to understand that H(P,P) must provide the halt status
of its actual input on the basis of the actual behavior specified by
this actual input?

It is just like you are insisting that you know for sure that sum(3,4)
is definitely 12. How nuts is that?

> What ever you are hiding by
> all that waffle, it's just a way to avoid having to say that H(P,P) ==
> false even though P(P) halts.
>
> You've recently tried to imply that it's somehow invalid for is to even
> ask for a D such that D(X,Y) == true if and only if X(Y) halts and false
> otherwise, because X(Y) is not "an input". But that's just a recent
> ruse. You've known how the C-version of the halting problem is defined
> for years.
>


--
Copyright 2022 Pete Olcott

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

[olcott]

On 5/7/2022 6:35 PM, Dennis Bush wrote:

> Then why do you insist that H(P,P) must return the value of H(Pn,Pn)?

The definition of decider requires it to based its decision on whatever
its input specifies.

Both H(P,P) and H1(P,P) use this exact literal byte string as their
input therefore it seems enormously dishonest of you to refer to the
same literal string using different subscripts indicating a difference
of the same string with itself.

558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3

_P()
[000009d6](01) 55 push ebp
[000009d7](02) 8bec mov ebp,esp
[000009d9](03) 8b4508 mov eax,[ebp+08]
[000009dc](01) 50 push eax // push P
[000009dd](03) 8b4d08 mov ecx,[ebp+08]
[000009e0](01) 51 push ecx // push P
[000009e1](05) e840feffff call 00000826 // call H
[000009e6](03) 83c408 add esp,+08
[000009e9](02) 85c0 test eax,eax
[000009eb](02) 7402 jz 000009ef
[000009ed](02) ebfe jmp 000009ed
[000009ef](01) 5d pop ebp
[000009f0](01) c3 ret // Final state
Size in bytes:(0027) [000009f0]

>>
>> Why is it so hard to understand that H(P,P) must provide the halt status
>> of its actual input on the basis of the actual behavior specified by
>> this actual input?
>

> The *definition* of the problem states that the actual behavior of the actual input to H(P,P) is P(P).

Whomever wrote that definition also knows that

THIS IS SET IN STONE:
All deciders only compute the mapping from their input parameters to an
accept/reject state on the basis of the actual properties actually
specified by this input

THIS LOGICALLY FOLLOWS FROM THAT:
Since a halt decider is a type of decider this means that all halt
deciders only compute the mapping from their input parameters to an
accept/reject state on the basis of the actual behavior actually
specified by this input.

This means that they simply made the false assumption that the correctly
simulated input to every simulating halt decider must always have
exactly the same behavior as the direct execution of this input.

It is a weird exception that they never noticed because they never
bothered to pursue simulating halt deciders applied to the HP to its
logical conclusion.

> You *say* there is infinite simulation but there is not *because* the copy of H inside P *will* abort.
>

I HAVE LITERALLY SAID THIS HUNDREDS OF TIMES
I say that the correctly simulated input to H(P,P) never reaches its
final state (thus never halts) whether or not its simulation is aborted.

> If by "the actual behavior of the actual input" you mean "can the decider simulate the input to a final state", then that means that any simulating halt decider that reports non-halting is necessarily correct,

Although technically correct use of terms I consider this utterly
ridiculous to say that a decider decides when all it does it guess.

I don't consider that a decder has decided anything unless it also
proves that its decision is correct. H(P,P)==false does that.
H1(P,P)==true also does that.

> which means that Ha3(N,5) == false is necessarily correct because by your definition "the

Can we please quite talking about you crackpot H3 that was intentionally
designed to get the wrong answer ???

actual behavior of the actual input" to Ha3(N,5) is non-halting.
>
> Or you can just admit that H is unable to meet the requirements as specified:
>
> H(P,P) == true if and only if P(P) halts, and
> H(P,P) == false if and only if P(P) does not halt
>

The requirements contradict the definition of a decider.
The author of these requirements was not aware of that.

> And yes, H is expected by this definition to decide on non-inputs because the inputs represent non-inputs.

That is exactly the same as requiring sum(3,4) to return 12, quite nuts.