Re: D correctly simulated by H proved for THREE YEARS --- finite sting transfermentations

joes <[email protected]> Thu, 13 Jun 2024 17:06:27 -0000 (UTC)
Newsgroups comp.theory,alt.crackpot
Organization i2pn2 (i2pn.org)
Message-ID <[email protected]>
Am Thu, 13 Jun 2024 08:07:35 -0500 schrieb olcott:
> On 6/13/2024 3:12 AM, joes wrote:
>> Am Wed, 12 Jun 2024 20:50:42 -0500 schrieb olcott:
>>> On 6/12/2024 8:36 PM, Richard Damon wrote:
>>>> On 6/12/24 9:27 PM, olcott wrote:
>>>>> On 6/12/2024 7:52 PM, Richard Damon wrote:
>>>>>> On 6/12/24 8:37 PM, olcott wrote:
>>>>>>> On 6/12/2024 6:45 PM, Richard Damon wrote:
>>>>>>>> On 6/12/24 7:25 PM, olcott wrote:
>>>>>>>>> On 6/12/2024 6:03 PM, Richard Damon wrote:
>>>>>>>>>> On 6/12/24 12:57 PM, olcott wrote:
>>>>>>>>>>> On 6/12/2024 6:33 AM, Richard Damon wrote:

>>>>>>>>> H(D,D) must compute the mapping from its finite string input
>>>>>>>>> transforming the finite string of its input into the behavior
>>>>>>>>> that it specifies using finite string transformation rules.
>> And give the right answer: does D(D) halt?

>>>>>>>> that Question is about the behavior of the direct execution of
>>>>>>>> the machine represented by its input.
>>>>>>> *H is not even being asked that question*
>> Oh yes, it is. We want to know if D(D) halts.
Why would we ask a machine "What is your own result?"?

>>>>>> Because the question being asked of *ALL* halt deciders, is "Does
>>>>>> the machine/input described by its input halt when it is run?"
>>>>> THAT IS NOT THE QUESTION THAT IS BEING ASKED.
>> H answers the wrong question.
It answers "I give this result, because I say so". The opposite were
equally valid.

>>>>> H must derive the question that it is being asked by computing the
>>>>> mapping from its finite string input to the behavior specified by
>>>>> this finite string input.
>>>> So, Definitions don't mean anything?
>>> Halt deciders are not being asked English questions nitwit.
>> Nitwit. It can't derive the answer.

>>> H must compute question that it is being asked.
If H doesn't, it is not what we are looking for.
>> Which is "does D(D) halt?", not "can I simulate this?".
> Halt deciders do not generally understand English, your assumption that
> they do is ridiculously false.
Of course not. Ridiculous is your assumption that I wasn't talking about
its specification.

> H(D,D) computes the mapping from its finite string input to derive the
> behavior that it must report on.
The behaviour of D(D) itself doesn't change by whatever H does.

> int sum(int x, int y) {return x + y; }
> sum(3,4) must provide the sum of 3+4 EVEN IF YOU EXPECT OTHERWISE.
Yes, and sum {return x*y} is a faulty implementation. Why would I expect
otherwise?

> H(D,D) must provide that halt status of D correctly simulated by H EVEN
> IF YOU EXPECT OTHERWISE.
It must provide the halt status, whether simulated by anything or not.
A simulation that changes it is called wrong.

> You may believe in your mind that H(D,D) must report on the behavior of
> D(D) yet H(D,D) does not share this belief.
Then I don't care about H. I want my H to report on D(D).

> There is no path from the input to H(D,D) by applying finite string
> transformation rules to the input to derived the behavior of D(D).
Which is why a halt decider is impossible.

>>> The question that H computes IS NOT THE BEHAVIOR OF D(D). IT DOES NOT
>>> MATTER HOW MUCH IT IS SUPPOSED TO DO THAT.
>> Then H is not the halt decider you are looking for.
The H that violates the specification is not the true H.

-- 
joes