On 9/25/21 12:18 PM, olcott wrote:
> On 9/25/2021 11:09 AM, Richard Damon wrote:
>> On 9/25/21 10:09 AM, olcott wrote:
>>> On 9/25/2021 5:06 AM, Richard Damon wrote:
>>>> On 9/25/21 12:31 AM, olcott wrote:
>>>>> On 9/24/2021 10:36 PM, olcott wrote:
>>>>>> On 9/24/2021 9:27 PM, Richard Damon wrote:
>>>>>>> On 9/24/21 9:52 PM, olcott wrote:
>>>>>>>> On 9/24/2021 8:27 PM, Richard Damon wrote:
>>>>>>>>> On 9/24/21 8:48 PM, olcott wrote:
>>>>>>>>>> On 9/24/2021 7:09 PM, Richard Damon wrote:
>>>>>>>>>>> On 9/24/21 10:49 AM, olcott wrote:
>>>>>>>>>>>> On 9/23/2021 10:39 PM, Richard Damon wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 9/23/21 11:27 PM, olcott wrote:
>>>>>>>>>>>>>> On 9/23/2021 9:09 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 9/23/21 2:30 PM, olcott wrote:
>>>>>>>>>>>>>>>> #include <stdint.h>
>>>>>>>>>>>>>>>> #define ptr uintptr_t
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> int H(ptr p, ptr i)
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> // Determine infinitely nested x86 emulation
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>          H(x, x);
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>          printf("H is called in infinitely nested
>>>>>>>>>>>>>>>> emulation =
>>>>>>>>>>>>>>>> ", H(P,
>>>>>>>>>>>>>>>> P));
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> H would use an x86 emulator to emulate its input in debug
>>>>>>>>>>>>>>>> step
>>>>>>>>>>>>>>>> mode.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Since people are telling me that my solution is incorrect
>>>>>>>>>>>>>>>> I am
>>>>>>>>>>>>>>>> giving
>>>>>>>>>>>>>>>> them an opportunity to either correct my errors or failing
>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> show
>>>>>>>>>>>>>>>> that their software engineering skills are insufficient to
>>>>>>>>>>>>>>>> analyze the
>>>>>>>>>>>>>>>> problem as presented.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is quite possible in the realm of H to detect that it has
>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>> called
>>>>>>>>>>>>>>> in 'recursion', i.e. that one instance of H has been invoked
>>>>>>>>>>>>>>> within
>>>>>>>>>>>>>>> another instance of H with the same parameters. You code
>>>>>>>>>>>>>>> does
>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>> successfully.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Since this H is only a limited decider, since the program
>>>>>>>>>>>>>>> to be
>>>>>>>>>>>>>>> decided
>>>>>>>>>>>>>>> is FORCED to be in the same address space as H, the trick of
>>>>>>>>>>>>>>> detecting
>>>>>>>>>>>>>>> the address of H in the simulated machine, and that must
>>>>>>>>>>>>>>> be a
>>>>>>>>>>>>>>> 'copy' of
>>>>>>>>>>>>>>> this H. (This also means that H isn't the requried
>>>>>>>>>>>>>>> decider of
>>>>>>>>>>>>>>> Linz, as
>>>>>>>>>>>>>>> it can't accept ANY input machine, but only those that fit
>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>> limited
>>>>>>>>>>>>>>> model.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is sufficiently the same thing in that it implements the
>>>>>>>>>>>>>> essence of
>>>>>>>>>>>>>> the liar paradox pattern.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I thought you were working on that Halting Problem. It
>>>>>>>>>>>>> needs to
>>>>>>>>>>>>> sufficienty recreate the Linz H/H^ pattern and decide that.
>>>>>>>>>>>>> This
>>>>>>>>>>>>> requires H to be a real computation, and H^ built sufficiently
>>>>>>>>>>>>> like
>>>>>>>>>>>>> Linz
>>>>>>>>>>>>> does.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I hypothesize that you are either a liar or incompetent about
>>>>>>>>>>>> what is
>>>>>>>>>>>> and what is not an actual computation. The term of the art for
>>>>>>>>>>>> this is
>>>>>>>>>>>> "computable function", therefore if you are not a liar or
>>>>>>>>>>>> incompetent
>>>>>>>>>>>> you would be able to cite sources that conform your
>>>>>>>>>>>> assessments.
>>>>>>>>>>>
>>>>>>>>>>> There is a difference between a Computable Function and a
>>>>>>>>>>> Computation,
>>>>>>>>>>> but it might be too subtle for you.
>>>>>>>>>>>
>>>>>>>>>>> A Computible Function is the actual Mapping, that happens to be
>>>>>>>>>>> computable, i.e. there exists an algorithm that is able to
>>>>>>>>>>> generate
>>>>>>>>>>> that
>>>>>>>>>>> mapping.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I derive a unique mapping from an input finite string to a
>>>>>>>>>> Boolean
>>>>>>>>>> value. I currently need static local data to do this,
>>>>>>>>>> none-the-less a
>>>>>>>>>> unique mapping is derived. I can't understand how this is
>>>>>>>>>> computable in
>>>>>>>>>> C and not computable in a TM.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The problem is that to be a Computatable Function ALL refereces to
>>>>>>>>> that
>>>>>>>>> Function need to generate that same mapping.
>>>>>>>>>
>>>>>>>>> That means that the P that call this 'Computable Function' H must
>>>>>>>>> get
>>>>>>>>> the exact same answer as H give when just asked.
>>>>>>>>
>>>>>>>> So we are back to a function called in infinite recursion must
>>>>>>>> return to
>>>>>>>> its caller even though everyone know this is impossible.
>>>>>>>
>>>>>>> Except that it ISN'T infinite recursion, since EVERY H will abort
>>>>>>> its
>>>>>>> simulation and return after finite time.
>>>>>>>
>>>>>>> Do you not understand that fact?
>>>>>>>
>>>>>>
>>>>>> If the question was:
>>>>>> Does P on its input stop running?
>>>>>> Then H provides the wrong answer.
>>>>>>
>>>>>> THIS IS NOT THE QUESTION
>>>>>> THIS IS NOT THE QUESTION
>>>>>> THIS IS NOT THE QUESTION
>>>>>> THIS IS NOT THE QUESTION
>>>>>>
>>>>>> I have told you this many hundreds of times so I estimate that you
>>>>>> may
>>>>>> have an actual neurological disorder.
>>>>>
>>>>> I must correct my mistakes when I become aware of them. In this
>>>>> case you
>>>>> made no mistake and were only going by the title of the post. I
>>>>> apologize for my mistake.
>>>>>
>>>>> H detects that its input never reaches its final state.
>>>>>
>>>>
>>>> Again, you use that bad terminology.
>>>>
>>>
>>> When the context has been that H is a simulating halt decider that
>>> simulates its input and I have told you this at least a thousand times
>>> pretending to forget that I said this is a real jackass move.
>>
>> But since you keep on saying that even though the machine that the input
>> represents is admittdly halting, somehow 'the input' isn't, so you can't
>> be using the standard definiton.
>>
>>>
>>>> Inputs don't actually DO anything.
>>>>
>>>> The program P (P) that is the machine the input to H represents, does
>>>> reach its final state, and thus is a Halting Computation.
>>>>
>>>
>>> It is a verifiable fact that the input to H(P,P) cannot possibly reach
>>> its final state whether or not H stops simulating it. It is a verifiable
>>> fact that H does simulate P(P) correctly. That you disagree without
>>> knowing the x86 language well enough to comprehend the proof that I am
>>> correct is a real jackass move.
>>
>>
>> Again, you misuse the term. Inputs don't do anything.
>>
>> When H does abort its simulation of its input, then the machine that the
>> simulation represent does halt. That is a fact.
>>
>
> That is a subtle dishonest dodge strawman error.
>
> int main() { H(P,P); } is a distinctly different computation than
> int main() { P(P); }
> int main() { H1(P,P); } is equivalent to int main() { P(P); }
>
>
>

Right, H(P,P) is not the SAME COMPUTATION as P(P) but is a decider whose
answer is supposed to predict what the second does.

H1(P,P) is another decider. Since P is built for H and not H1, the Linz
proof only talks about what H can't do, and the fact that H and H1 give
different answers says they are NOT the same thing, so H1 getting it
right doesn't matter.

All you claims to the contrary just show you are lying about something.

Either their code isn't the same, or
The code takes some other hidden input which is different, so H/H1 is
disqualified to be the Halt Decider since it isn't the right form, or

The code for H/H1 isn't actually a computation because it isn't a
complete 'algorithm'.