olcott <NoOne@NoWhere.com> writes:

> On 4/25/2022 4:19 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/24/2022 6:56 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> The key fact (that is perpetually over your head) is that the input to
>>>>> H(P,P) specifies a non-halting sequence of configurations making it
>>>>> necessarily correct for H to reject this input.
>>>> By prior definition, the two pointers passed to H denote a computation
>>>> whose halting or otherwise H should determine. H(P,P)==false is wrong
>>>> because P(P) halts.
>>>
>>> Only if we assume that P(P) is computationally equivalent to the
>>> correct simulation of the input to H(P,P).
>> The halting problem is as stated regardless of whether P(P) is or not
>> computationally equivalent to anything else. The issue is that no
>> C-like code can return true for H(X,Y) if and only if X(Y) halts
>> (technically returns) and false otherwise. You H fails by definition.
>
> A halt decider cannot be a mind reader. It must report on the actual
> behavior of the actual input.

No mind reading is needed (though it is none the less impossible). The
two parameters to H refer to everything H could possibly need to make
the decision -- the entire machine code of P and the parameter to be
passed to that code.

Of course it would be clearer if these were strings describing a whole
program and its input, but you rejected that as "extraneous complexity"
long ago. C does not technically permit code to inspect code through a
function pointer, but we've always been talking about a C-like language.

> Because of pathological self-reference P(P) has different behavior
> than the correct simulation of the input to H(P,P). That you deny this
> when you don't know the x86 language is dishonest.

You simply won't read what I say will you? Or if you do read what I
say, you don't understand it and just make assumptions. Go back to any
one of the dozen or so times I deconstructed your new mantra and you'll
see I don't "deny" it -- I tell you in detail why it is either wrong or
irrelevant.

H(P,P) == false wrong because P(P) halts. Whatever other computation
you are imagining H being correct about is beside the point. What H
must determine is not for you to say. I.e.:

>> Every crank thread eventually comes down to rejected definitions. You
>> are free to address the other problem which deals with whatever other
>> you think is not "computationally equivalent" to P(P), but there is no
>> pressing reason for anyone to care about it. The rest of the world want
>> H(X,Y) to be correct about X(Y).

--
Ben.
"le génie humain a des limites, quand la bêtise humaine n’en a pas"
Alexandre Dumas (fils)

On 4/25/2022 8:29 PM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/25/2022 4:19 PM, Ben wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 4/24/2022 6:56 PM, Ben wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> The key fact (that is perpetually over your head) is that the input to
>>>>>> H(P,P) specifies a non-halting sequence of configurations making it
>>>>>> necessarily correct for H to reject this input.
>>>>> By prior definition, the two pointers passed to H denote a computation
>>>>> whose halting or otherwise H should determine. H(P,P)==false is wrong
>>>>> because P(P) halts.
>>>>
>>>> Only if we assume that P(P) is computationally equivalent to the
>>>> correct simulation of the input to H(P,P).
>>> The halting problem is as stated regardless of whether P(P) is or not
>>> computationally equivalent to anything else. The issue is that no
>>> C-like code can return true for H(X,Y) if and only if X(Y) halts
>>> (technically returns) and false otherwise. You H fails by definition.
>>
>> A halt decider cannot be a mind reader. It must report on the actual
>> behavior of the actual input.
>
> No mind reading is needed (though it is none the less impossible). The
> two parameters to H refer to everything H could possibly need to make
> the decision -- the entire machine code of P and the parameter to be
> passed to that code.
>
> Of course it would be clearer if these were strings describing a whole
> program and its input, but you rejected that as "extraneous complexity"
> long ago. C does not technically permit code to inspect code through a
> function pointer, but we've always been talking about a C-like language.
>
>> Because of pathological self-reference P(P) has different behavior
>> than the correct simulation of the input to H(P,P). That you deny this
>> when you don't know the x86 language is dishonest.
>
> You simply won't read what I say will you? Or if you do read what I
> say, you don't understand it and just make assumptions. Go back to any
> one of the dozen or so times I deconstructed your new mantra and you'll
> see I don't "deny" it -- I tell you in detail why it is either wrong or
> irrelevant.
>
> H(P,P) == false wrong because P(P) halts.

That is like saying 2 + 7 = 43 because 30 + 13 = 43.

Intuitively H(P,P) and P(P) are related empirically they are unrelated,
facts supersede opinions.

--
Copyright 2022 Pete Olcott

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

On 4/26/22 5:30 PM, olcott wrote:
> On 4/25/2022 8:29 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/25/2022 4:19 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/24/2022 6:56 PM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> The key fact (that is perpetually over your head) is that the
>>>>>>> input to
>>>>>>> H(P,P) specifies a non-halting sequence of configurations making it
>>>>>>> necessarily correct for H to reject this input.
>>>>>> By prior definition, the two pointers passed to H denote a
>>>>>> computation
>>>>>> whose halting or otherwise H should determine.  H(P,P)==false is
>>>>>> wrong
>>>>>> because P(P) halts.
>>>>>
>>>>> Only if we assume that P(P) is computationally equivalent to the
>>>>> correct simulation of the input to H(P,P).
>>>> The halting problem is as stated regardless of whether P(P) is or not
>>>> computationally equivalent to anything else.  The issue is that no
>>>> C-like code can return true for H(X,Y) if and only if X(Y) halts
>>>> (technically returns) and false otherwise.  You H fails by definition.
>>>
>>> A halt decider cannot be a mind reader. It must report on the actual
>>> behavior of the actual input.
>>
>> No mind reading is needed (though it is none the less impossible).  The
>> two parameters to H refer to everything H could possibly need to make
>> the decision -- the entire machine code of P and the parameter to be
>> passed to that code.
>>
>> Of course it would be clearer if these were strings describing a whole
>> program and its input, but you rejected that as "extraneous complexity"
>> long ago.  C does not technically permit code to inspect code through a
>> function pointer, but we've always been talking about a C-like language.
>>
>>> Because of pathological self-reference P(P) has different behavior
>>> than the correct simulation of the input to H(P,P). That you deny this
>>> when you don't know the x86 language is dishonest.
>>
>> You simply won't read what I say will you?  Or if you do read what I
>> say, you don't understand it and just make assumptions.  Go back to any
>> one of the dozen or so times I deconstructed your new mantra and you'll
>> see I don't "deny" it -- I tell you in detail why it is either wrong or
>> irrelevant.
>>
>> H(P,P) == false wrong because P(P) halts.
>
> That is like saying 2 + 7 = 43 because 30 + 13 = 43.
>
> Intuitively H(P,P) and P(P) are related empirically they are unrelated,
> facts supersede opinions.
>
>

If H(P,P) is NOT asking about P(P), then BY DEFINITION, H fails to be a
Halt Decider.

THAT is fact.

This is empiricaaly shown as H(P,P) says non-halting while P(P) Halts.

Since THE DEFINITION of a Halt Decider is H(M,w) is supposed to say
Halting of M(w) Halts, and Non-Halting of M(w) never halts, your H is BY
DEFINITION WRONG.

The definition of a Halt Decider NEVER askes about "the behavior of the
input, and in fact, the designer of the Halt Decider needs to DEFINE how
to build the input to ask the right question.

You H fails to meet that requirement if the input has been constructed
incorrectly.

That is like asking for the sum of 3 and 5, and you enter SUM(5, 6) and
says that this must be right as the answer is the sum of its inputs.

If you build the wrong question to your decider, if gives the wrong answer.

olcott <NoOne@NoWhere.com> writes:

> On 4/25/2022 8:29 PM, Ben wrote:

>> H(P,P) == false wrong because P(P) halts.
>
> That is like saying 2 + 7 = 43 because 30 + 13 = 43.

What a silly thing to say. H(X,Y) should be true if, and only if X(Y)
halts, and false otherwise. Your H does not meet this specification.

Do you accept the a halt decider as I have specified it -- one that
reports on the halting of the function call formed from its two
arguments -- can't be written?

And for someone who does not like the idea of undecidable problems,
you'll have to address it again some time. (I say again because you've
known what H should really do in the past.)

--
Ben.
"le génie humain a des limites, quand la bêtise humaine n’en a pas"
Alexandre Dumas (fils)