On 9/25/21 9:58 AM, olcott wrote:
> On 9/25/2021 5:03 AM, Richard Damon wrote:
>> On 9/24/21 11: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.
>>>
>>
>> But it IS the question that the Halt Decider is SUPPOSED to be answering.
>>
>> If you have decided you need to answer some different question, fine,
>> you just aren't working on the Halting Problem.
>>
>> PERIOD. DEFINITION.
>>
>
> Whether or not the input P ever reaches its final state is an equivalent
> question.
>

Again, you speak non-sense.

The 'Input' doesn't ever actually DO anything. It is merely a string of
symbols.

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.

> 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.
>

On 9/25/2021 9:07 AM, Richard Damon wrote:
> On 9/25/21 9:58 AM, olcott wrote:
>> On 9/25/2021 5:03 AM, Richard Damon wrote:
>>> On 9/24/21 11: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.
>>>>
>>>
>>> But it IS the question that the Halt Decider is SUPPOSED to be answering.
>>>
>>> If you have decided you need to answer some different question, fine,
>>> you just aren't working on the Halting Problem.
>>>
>>> PERIOD. DEFINITION.
>>>
>>
>> Whether or not the input P ever reaches its final state is an equivalent
>> question.
>>
>
> Again, you speak non-sense.
>
> The 'Input' doesn't ever actually DO anything. It is merely a string of
> symbols.
>
> The Actual Machine that this input represets, DO reach its final state.
>
> Do you now want to try to deny that this is what happens?
>

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.

On 9/25/21 10:18 AM, olcott wrote:
> On 9/25/2021 9:07 AM, Richard Damon wrote:
>> On 9/25/21 9:58 AM, olcott wrote:
>>> On 9/25/2021 5:03 AM, Richard Damon wrote:
>>>> On 9/24/21 11: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.
>>>>>
>>>>
>>>> But it IS the question that the Halt Decider is SUPPOSED to be
>>>> answering.
>>>>
>>>> If you have decided you need to answer some different question, fine,
>>>> you just aren't working on the Halting Problem.
>>>>
>>>> PERIOD. DEFINITION.
>>>>
>>>
>>> Whether or not the input P ever reaches its final state is an equivalent
>>> question.
>>>
>>
>> Again, you speak non-sense.
>>
>> The 'Input' doesn't ever actually DO anything. It is merely a string of
>> symbols.
>>
>> The Actual Machine that this input represets, DO reach its final state.
>>
>> Do you now want to try to deny that this is what happens?
>>
>
> When I say that I have a black cat proof that I do not have a white dog
> is the strawman error that I have been calling a dishonest dodge.

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.
>

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

On Fri, 24 Sep 2021 22:36:33 -0500
olcott <NoOne@NoWhere.com> 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.

What qualifications do you have for diagnosing medical disorders over
Usenet?

/Flibble

On 9/25/2021 11:54 AM, Mr Flibble wrote:
> On Fri, 24 Sep 2021 22:36:33 -0500
> olcott <NoOne@NoWhere.com> 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.
>
> What qualifications do you have for diagnosing medical disorders over
> Usenet?

That's obvious: He was an observant person when his/her mental disorders
were evaluated and now he thinks he's the expert. Doctor vs Patient
confusion; Professor vs Student confusion; Interesting vs Pathetic
confusion; Clever vs Lost confusion.

I hope the above is helpful.
--
Jeff Barnett

On 9/25/2021 12:54 PM, Mr Flibble wrote:
> On Fri, 24 Sep 2021 22:36:33 -0500
> olcott <NoOne@NoWhere.com> 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.
>
> What qualifications do you have for diagnosing medical disorders over
> Usenet?
>
> /Flibble
>

(1) This case was my mistake and I apologized.

(2) When you tell an intelligent person a key point
many hundreds of times and they keep forgetting it
something is definitely wrong.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

olcott <NoOne@NoWhere.com> writes:

> I derive a unique mapping from an input finite string to a Boolean
> value.

But is it a function? And is it a function from S* to {true, false}
(for some finite alphabet S)? It might be, but since you only found out
what a function is a few months ago, it's wise to ask.

Your term "unique mapping from an input finite string to a Boolean
value" is what a coder would say. It's not the same as a mathematician
saying "f: S* -> {true, false}".

> 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.

_Bool f(char *s) { return s; }

is a C function that maps finite strings input strings to Boolean
values. It has no corresponding TM.

--
Ben.

On 9/25/2021 2:54 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> I derive a unique mapping from an input finite string to a Boolean
>> value.
>
> But is it a function? And is it a function from S* to {true, false}
> (for some finite alphabet S)? It might be, but since you only found out
> what a function is a few months ago, it's wise to ask.
>
> Your term "unique mapping from an input finite string to a Boolean
> value" is what a coder would say. It's not the same as a mathematician
> saying "f: S* -> {true, false}".
>

"If the procedure is given a k-tuple x in the domain of f, then after a
finite number of discrete steps the procedure must terminate and produce
f(x)."

https://en.wikipedia.org/wiki/Computable_function#Characteristics_of_computable_functions

This is typically understood to be a k-tuple x in the domain of f, of
natural numbers to a natural number.

In other words a mathematical mapping from a finite string to an integer.

>> 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.
>
> _Bool f(char *s) { return s; }
>
> is a C function that maps finite strings input strings to Boolean
> values. It has no corresponding TM.
>

So you are saying that a k-tuple of ASCII values mapped to one element
of the set {0, 1} has no corresponding TM ?

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

olcott <NoOne@NoWhere.com> writes:

> On 9/24/2021 6:22 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 9/24/2021 3:54 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>> if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ halts, and
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>> if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt
>>>> This is wrong since, apparently,
>>>> "I always used this symbol Ĥ in the context of the Linz proofs and
>>>> never used it in any other way"
>>>> If Ĥ refers to the Ĥ in Linz's proof your annotations are incorrect, and
>>>> if Ĥ is being using "in the context of the Linz proof" but denotes
>>>> something else (what?) then you are not being serious.
>>>
>>> As you have indicated that you have recalled I corrected the error in
>>> the Linz specification that had two start states by changing one of
>>> these start states to qx.
>> Not the issue. (Though I'll note again that you don't use the notation
>> you came up with in a helpful way. There is no need for qx because it
>> could be called H.q0 or, better yet, H.0.)
>>
>>> After this I augmented the Linz notation further so that it showed the
>>> notation when the Linz Ĥ is specifically applied to the Linz ⟨Ĥ⟩ where
>>> the halt decider embedded at qx is a simulating halt decider.
>> Not the issue but if you used the . notation better this would be much clearer.
>>
>>> Since Linz does not exclude simulating halt deciders this is still the
>>> Linz Ĥ.
>>
>> You annotations are incorrect. If you'd like to know why, ask an
>> intelligent question. But why are you making any claims at all about
>> TMs that don't exist?
>
> How would you annotate all of the steps of the Linz Ĥ applied to its
> own machine description?

What new nonsense is this? No one is annotating "all of the steps" of a
TM. The annotations explain which formal statements apply in which
situations:

Ĥ.q0 ⟨Ĥ⟩ ⊢* ∞ if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.

--
Ben.

On 9/25/2021 3:43 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 9/24/2021 6:22 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 9/24/2021 3:54 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>> if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ halts, and
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>> if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt
>>>>> This is wrong since, apparently,
>>>>> "I always used this symbol Ĥ in the context of the Linz proofs and
>>>>> never used it in any other way"
>>>>> If Ĥ refers to the Ĥ in Linz's proof your annotations are incorrect, and
>>>>> if Ĥ is being using "in the context of the Linz proof" but denotes
>>>>> something else (what?) then you are not being serious.
>>>>
>>>> As you have indicated that you have recalled I corrected the error in
>>>> the Linz specification that had two start states by changing one of
>>>> these start states to qx.
>>> Not the issue. (Though I'll note again that you don't use the notation
>>> you came up with in a helpful way. There is no need for qx because it
>>> could be called H.q0 or, better yet, H.0.)
>>>
>>>> After this I augmented the Linz notation further so that it showed the
>>>> notation when the Linz Ĥ is specifically applied to the Linz ⟨Ĥ⟩ where
>>>> the halt decider embedded at qx is a simulating halt decider.
>>> Not the issue but if you used the . notation better this would be much clearer.
>>>
>>>> Since Linz does not exclude simulating halt deciders this is still the
>>>> Linz Ĥ.
>>>
>>> You annotations are incorrect. If you'd like to know why, ask an
>>> intelligent question. But why are you making any claims at all about
>>> TMs that don't exist?
>>
>> How would you annotate all of the steps of the Linz Ĥ applied to its
>> own machine description?
>
> What new nonsense is this? No one is annotating "all of the steps" of a
> TM. The annotations explain which formal statements apply in which
> situations:
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* ∞ if Ĥ applied to ⟨Ĥ⟩ halts, and
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.
>

You skipped some Linz specified states.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

olcott <NoOne@NoWhere.com> writes:

> On 9/25/2021 2:54 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> I derive a unique mapping from an input finite string to a Boolean
>>> value.
>>
>> But is it a function? And is it a function from S* to {true, false}
>> (for some finite alphabet S)? It might be, but since you only found out
>> what a function is a few months ago, it's wise to ask.
>> Your term "unique mapping from an input finite string to a Boolean
>> value" is what a coder would say. It's not the same as a mathematician
>> saying "f: S* -> {true, false}".
>
> "If the procedure is given a k-tuple x in the domain of f, then after
> a finite number of discrete steps the procedure must terminate and
> produce f(x)."
>
> https://en.wikipedia.org/wiki/Computable_function#Characteristics_of_computable_functions

Thank you, but I know what a computable function is. I was asking if
you are sure that what you loosely describe as "a unique mapping from an
input finite string to a Boolean value" is indeed a function.

> This is typically understood to be a k-tuple x in the domain of f, of
> natural numbers to a natural number.
>
> In other words a mathematical mapping from a finite string to an
> integer.

No. "In other words" means using different words to convey the same
meaning. You've change the meaning with your "other words".

But don't worry about it. It's all details, and you don't do details.
The key point is that we still don't know if what you have "derived" is
a function or not, because you have not said whether it is or not.

>>> 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.
>>
>> _Bool f(char *s) { return s; }
>>
>> is a C function that maps finite strings input strings to Boolean
>> values. It has no corresponding TM.
>
> So you are saying that a k-tuple of ASCII values mapped to one element
> of the set {0, 1} has no corresponding TM ?

No. I wonder what is confusing you? I tried to give a simple example
to show that your woolly words are not enough, and to help you see that
you should not be baffled by a claim that you might have some C code
that "computes" something that is not TM-computable.

To be fair, I don't think you are pulling any such tricks. If you were,
surely you would have arranged for your partial decider to give the
right answer, rather than the wrong one? A partial halt decider being
wrong about it's confounding problem instance does not require any
trickery at all.

--
Ben.

olcott <NoOne@NoWhere.com> writes:

> On 9/25/2021 3:43 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 9/24/2021 6:22 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 9/24/2021 3:54 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>> if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ halts, and
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>> if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt
>>>>>> This is wrong since, apparently,
>>>>>> "I always used this symbol Ĥ in the context of the Linz proofs and
>>>>>> never used it in any other way"
>>>>>> If Ĥ refers to the Ĥ in Linz's proof your annotations are incorrect, and
>>>>>> if Ĥ is being using "in the context of the Linz proof" but denotes
>>>>>> something else (what?) then you are not being serious.
>>>>>
>>>>> As you have indicated that you have recalled I corrected the error in
>>>>> the Linz specification that had two start states by changing one of
>>>>> these start states to qx.
>>>> Not the issue. (Though I'll note again that you don't use the notation
>>>> you came up with in a helpful way. There is no need for qx because it
>>>> could be called H.q0 or, better yet, H.0.)
>>>>
>>>>> After this I augmented the Linz notation further so that it showed the
>>>>> notation when the Linz Ĥ is specifically applied to the Linz ⟨Ĥ⟩ where
>>>>> the halt decider embedded at qx is a simulating halt decider.
>>>> Not the issue but if you used the . notation better this would be much clearer.
>>>>
>>>>> Since Linz does not exclude simulating halt deciders this is still the
>>>>> Linz Ĥ.
>>>>
>>>> You annotations are incorrect. If you'd like to know why, ask an
>>>> intelligent question. But why are you making any claims at all about
>>>> TMs that don't exist?
>>>
>>> How would you annotate all of the steps of the Linz Ĥ applied to its
>>> own machine description?
>> What new nonsense is this? No one is annotating "all of the steps" of a
>> TM. The annotations explain which formal statements apply in which
>> situations:
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* ∞ if Ĥ applied to ⟨Ĥ⟩ halts, and
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.
>
> You skipped some Linz specified states.

Your annotations are still wrong. Mine (in fact Linz's) are the correct
ones regardless of whether I (or he) includes the states you are so
obsessed with.

Have another go. See if you can write the two lines about Ĥ.q0 ⟨Ĥ⟩
correctly with intermediate states you love so much.

If you post the lines with the wrong annotations again, I'll point out
that they are wrong again. At least you now know they are wrong.

--
Ben.

On 9/25/2021 4:15 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 9/25/2021 2:54 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> I derive a unique mapping from an input finite string to a Boolean
>>>> value.
>>>
>>> But is it a function? And is it a function from S* to {true, false}
>>> (for some finite alphabet S)? It might be, but since you only found out
>>> what a function is a few months ago, it's wise to ask.
>>> Your term "unique mapping from an input finite string to a Boolean
>>> value" is what a coder would say. It's not the same as a mathematician
>>> saying "f: S* -> {true, false}".
>>
>> "If the procedure is given a k-tuple x in the domain of f, then after
>> a finite number of discrete steps the procedure must terminate and
>> produce f(x)."
>>
>> https://en.wikipedia.org/wiki/Computable_function#Characteristics_of_computable_functions
>
> Thank you, but I know what a computable function is. I was asking if
> you are sure that what you loosely describe as "a unique mapping from an
> input finite string to a Boolean value" is indeed a function.
>
>> This is typically understood to be a k-tuple x in the domain of f, of
>> natural numbers to a natural number.
>>
>> In other words a mathematical mapping from a finite string to an
>> integer.
>
> No. "In other words" means using different words to convey the same
> meaning. You've change the meaning with your "other words".
>
> But don't worry about it. It's all details, and you don't do details.
> The key point is that we still don't know if what you have "derived" is
> a function or not, because you have not said whether it is or not.
>
>>>> 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.
>>>
>>> _Bool f(char *s) { return s; }
>>>
>>> is a C function that maps finite strings input strings to Boolean
>>> values. It has no corresponding TM.
>>
>> So you are saying that a k-tuple of ASCII values mapped to one element
>> of the set {0, 1} has no corresponding TM ?
>
> No. I wonder what is confusing you?

I thought that was a function declaration.
I did not notice the body.

> I tried to give a simple example
> to show that your woolly words are not enough, and to help you see that
> you should not be baffled by a claim that you might have some C code
> that "computes" something that is not TM-computable.
>
> To be fair, I don't think you are pulling any such tricks. If you were,
> surely you would have arranged for your partial decider to give the
> right answer, rather than the wrong one? A partial halt decider being
> wrong about it's confounding problem instance does not require any
> trickery at all.
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 9/25/21 3:54 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> I derive a unique mapping from an input finite string to a Boolean
>> value.
>
> But is it a function? And is it a function from S* to {true, false}
> (for some finite alphabet S)? It might be, but since you only found out
> what a function is a few months ago, it's wise to ask.
>
> Your term "unique mapping from an input finite string to a Boolean
> value" is what a coder would say. It's not the same as a mathematician
> saying "f: S* -> {true, false}".
>
>> 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.
>
> _Bool f(char *s) { return s; }
>
> is a C function that maps finite strings input strings to Boolean
> values. It has no corresponding TM.
>

Actually, you should be able to map that. The key is you need to define
how you encode character strings.

If the tape allows 257 values per cell, corresponding to 'no value' or
the ascii values 0-255, then the test is just is the cell we start at
the 'no value', which is the equivalent for a null pointer, and return
false/0 if it is, else return true.

There is almost ALWAYS a 'mapping' issue of how do you plan to represent
the various representations in one space to another.

One key is that as a whole computation, that is likely not all that
useful. and as a piece of a bigger program, you may well be rearranging
things from how the C code is organized as implementing things just like
C is very inefficient for a Turing Machine.

Richard Damon <Richard@Damon-Family.org> writes:

> On 9/25/21 3:54 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> I derive a unique mapping from an input finite string to a Boolean
>>> value.
>>
>> But is it a function? And is it a function from S* to {true, false}
>> (for some finite alphabet S)? It might be, but since you only found out
>> what a function is a few months ago, it's wise to ask.
>>
>> Your term "unique mapping from an input finite string to a Boolean
>> value" is what a coder would say. It's not the same as a mathematician
>> saying "f: S* -> {true, false}".
>>
>>> 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.
>>
>> _Bool f(char *s) { return s; }
>>
>> is a C function that maps finite strings input strings to Boolean
>> values. It has no corresponding TM.
>
> Actually, you should be able to map that. The key is you need to define
> how you encode character strings.
>
> If the tape allows 257 values per cell, corresponding to 'no value' or
> the ascii values 0-255, then the test is just is the cell we start at
> the 'no value', which is the equivalent for a null pointer, and return
> false/0 if it is, else return true.

OK, not the best example since you might consider that a natural
correspondence. I'd suggest, then,

_Bool f(char *s) { return (uintptr_t)s & 1; }

or

_Bool f(char *s) { return ((uintptr_t)s + (uintptr_t)f) & 0x8800; }

or

_Bool f(char *s) { return s && *s ? f(s+1) : (uintptr_t)&s & 1; }

> There is almost ALWAYS a 'mapping' issue of how do you plan to represent
> the various representations in one space to another.

Maybe. I think we may disagree about what a "corresponding TM" really
is. But that's not the main point I was trying to make: PO's words were
just too vague to address why he's puzzled that something "computable"
in C is not "computable" by a TM.

I agree that we can often define away the issue by being more specific.
The result is then a well-defined function that is can be implemented in
both C and realised as a TM, but lots of C code has no natural
corresponding TM (as I see it).

Also, I just wanted to reiterate why C is such a terrible choice, and
x86 code (RDRAND, anyone?) is even worse, as a formal model of
computation.

--
Ben.

On 9/25/21 5:54 PM, Ben Bacarisse wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> On 9/25/21 3:54 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> I derive a unique mapping from an input finite string to a Boolean
>>>> value.
>>>
>>> But is it a function? And is it a function from S* to {true, false}
>>> (for some finite alphabet S)? It might be, but since you only found out
>>> what a function is a few months ago, it's wise to ask.
>>>
>>> Your term "unique mapping from an input finite string to a Boolean
>>> value" is what a coder would say. It's not the same as a mathematician
>>> saying "f: S* -> {true, false}".
>>>
>>>> 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.
>>>
>>> _Bool f(char *s) { return s; }
>>>
>>> is a C function that maps finite strings input strings to Boolean
>>> values. It has no corresponding TM.
>>
>> Actually, you should be able to map that. The key is you need to define
>> how you encode character strings.
>>
>> If the tape allows 257 values per cell, corresponding to 'no value' or
>> the ascii values 0-255, then the test is just is the cell we start at
>> the 'no value', which is the equivalent for a null pointer, and return
>> false/0 if it is, else return true.
>
> OK, not the best example since you might consider that a natural
> correspondence. I'd suggest, then,
>
> _Bool f(char *s) { return (uintptr_t)s & 1; }
>
> or
>
> _Bool f(char *s) { return ((uintptr_t)s + (uintptr_t)f) & 0x8800; }
>
> or
>
> _Bool f(char *s) { return s && *s ? f(s+1) : (uintptr_t)&s & 1; }
>
>> There is almost ALWAYS a 'mapping' issue of how do you plan to represent
>> the various representations in one space to another.
>
> Maybe. I think we may disagree about what a "corresponding TM" really
> is. But that's not the main point I was trying to make: PO's words were
> just too vague to address why he's puzzled that something "computable"
> in C is not "computable" by a TM.
>
> I agree that we can often define away the issue by being more specific.
> The result is then a well-defined function that is can be implemented in
> both C and realised as a TM, but lots of C code has no natural
> corresponding TM (as I see it).
>
> Also, I just wanted to reiterate why C is such a terrible choice, and
> x86 code (RDRAND, anyone?) is even worse, as a formal model of
> computation.
>

If your 'specification' of what you are doing is C code, then you are
going to be forced to deal with a TM dealing with very Cish data types.
It might even turn out that the simplest model is to make the TM be a
RASP machine and start from there.

Note to PO, If you need to make a TM do a specific thing, sometimes the
right answer is to make into a RASP machine. But if you need to accept
ALL or ANY TM, you can't just limit yourself to RASP machines. And you
are dealing with FULL RASP machines, not just a 'subroutine' that is
part of a RASP machine.

On 9/25/2021 4:24 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 9/25/2021 3:43 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 9/24/2021 6:22 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 9/24/2021 3:54 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>> if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ halts, and
>>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>> if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt
>>>>>>> This is wrong since, apparently,
>>>>>>> "I always used this symbol Ĥ in the context of the Linz proofs and
>>>>>>> never used it in any other way"
>>>>>>> If Ĥ refers to the Ĥ in Linz's proof your annotations are incorrect, and
>>>>>>> if Ĥ is being using "in the context of the Linz proof" but denotes
>>>>>>> something else (what?) then you are not being serious.
>>>>>>
>>>>>> As you have indicated that you have recalled I corrected the error in
>>>>>> the Linz specification that had two start states by changing one of
>>>>>> these start states to qx.
>>>>> Not the issue. (Though I'll note again that you don't use the notation
>>>>> you came up with in a helpful way. There is no need for qx because it
>>>>> could be called H.q0 or, better yet, H.0.)
>>>>>
>>>>>> After this I augmented the Linz notation further so that it showed the
>>>>>> notation when the Linz Ĥ is specifically applied to the Linz ⟨Ĥ⟩ where
>>>>>> the halt decider embedded at qx is a simulating halt decider.
>>>>> Not the issue but if you used the . notation better this would be much clearer.
>>>>>
>>>>>> Since Linz does not exclude simulating halt deciders this is still the
>>>>>> Linz Ĥ.
>>>>>
>>>>> You annotations are incorrect. If you'd like to know why, ask an
>>>>> intelligent question. But why are you making any claims at all about
>>>>> TMs that don't exist?
>>>>
>>>> How would you annotate all of the steps of the Linz Ĥ applied to its
>>>> own machine description?
>>> What new nonsense is this? No one is annotating "all of the steps" of a
>>> TM. The annotations explain which formal statements apply in which
>>> situations:
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* ∞ if Ĥ applied to ⟨Ĥ⟩ halts, and
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.
>>
>> You skipped some Linz specified states.
>
> Your annotations are still wrong. Mine (in fact Linz's) are the correct
> ones regardless of whether I (or he) includes the states you are so
> obsessed with.
>

As always you can dogmatically assert that I am wrong yet cannot provide
any evidence of my error because there is in fact no error.

> Have another go. See if you can write the two lines about Ĥ.q0 ⟨Ĥ⟩
> correctly with intermediate states you love so much.
>

When the halt decider at Ĥ.qx is a simulating halt decider

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ halts, and

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt

> If you post the lines with the wrong annotations again, I'll point out
> that they are wrong again. At least you now know they are wrong.

You can't point out what is wrong about them because there is nothing
wrong about them. This may only be a lack of comprehension on your part.
I can't correct this lack without the details of your reasoning. Failing
to provide any details of your reasoning will revert to my intentional
deception hypothesis.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 9/25/2021 4:54 PM, Ben Bacarisse wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> On 9/25/21 3:54 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> I derive a unique mapping from an input finite string to a Boolean
>>>> value.
>>>
>>> But is it a function? And is it a function from S* to {true, false}
>>> (for some finite alphabet S)? It might be, but since you only found out
>>> what a function is a few months ago, it's wise to ask.
>>>
>>> Your term "unique mapping from an input finite string to a Boolean
>>> value" is what a coder would say. It's not the same as a mathematician
>>> saying "f: S* -> {true, false}".
>>>
>>>> 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.
>>>
>>> _Bool f(char *s) { return s; }
>>>
>>> is a C function that maps finite strings input strings to Boolean
>>> values. It has no corresponding TM.
>>
>> Actually, you should be able to map that. The key is you need to define
>> how you encode character strings.
>>
>> If the tape allows 257 values per cell, corresponding to 'no value' or
>> the ascii values 0-255, then the test is just is the cell we start at
>> the 'no value', which is the equivalent for a null pointer, and return
>> false/0 if it is, else return true.
>
> OK, not the best example since you might consider that a natural
> correspondence. I'd suggest, then,
>
> _Bool f(char *s) { return (uintptr_t)s & 1; }
>
> or
>
> _Bool f(char *s) { return ((uintptr_t)s + (uintptr_t)f) & 0x8800; }
>
> or
>
> _Bool f(char *s) { return s && *s ? f(s+1) : (uintptr_t)&s & 1; }
>
>> There is almost ALWAYS a 'mapping' issue of how do you plan to represent
>> the various representations in one space to another.
>
> Maybe. I think we may disagree about what a "corresponding TM" really
> is. But that's not the main point I was trying to make: PO's words were
> just too vague to address why he's puzzled that something "computable"
> in C is not "computable" by a TM.
>
> I agree that we can often define away the issue by being more specific.
> The result is then a well-defined function that is can be implemented in
> both C and realised as a TM, but lots of C code has no natural
> corresponding TM (as I see it).
>
> Also, I just wanted to reiterate why C is such a terrible choice, and
> x86 code (RDRAND, anyone?) is even worse, as a formal model of
> computation.
>

Yes because everyone knows the carefully studying a hundreds of
thousands of pages of execution trace is enormously easier than 14 lines
of execution trace. The 14 lines could take many decades of study before
understanding how the algorithm is applied whereas 500,000 pages can be
fully understood in less than a minute.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

olcott <NoOne@NoWhere.com> writes:

> On 9/25/2021 4:54 PM, Ben Bacarisse wrote:

>> Also, I just wanted to reiterate why C is such a terrible choice, and
>> x86 code (RDRAND, anyone?) is even worse, as a formal model of
>> computation.
>
> Yes because everyone knows the carefully studying a hundreds of
> thousands of pages of execution trace is enormously easier than 14
> lines of execution trace. The 14 lines could take many decades of
> study before understanding how the algorithm is applied whereas
> 500,000 pages can be fully understood in less than a minute.

Yet there are many interesting theorems about what can and can not be
computed using simple rigorous models. If you studied the subject you
would see why no one does this work in C.

Fortunately you are so wrong that no formal model is needed. In fact we
know you are wrong even though you've kept the code hidden! You have
(eventually) told us your code gives the wrong answer, and exactly why it
gives the wrong answer.

--
Ben.

olcott <NoOne@NoWhere.com> writes:

> On 9/25/2021 4:24 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 9/25/2021 3:43 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 9/24/2021 6:22 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 9/24/2021 3:54 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>> if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ halts, and
>>>>>>>>>
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>> if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt
>>>>>>>> This is wrong since, apparently,
>>>>>>>> "I always used this symbol Ĥ in the context of the Linz proofs and
>>>>>>>> never used it in any other way"
>>>>>>>> If Ĥ refers to the Ĥ in Linz's proof your annotations are incorrect, and
>>>>>>>> if Ĥ is being using "in the context of the Linz proof" but denotes
>>>>>>>> something else (what?) then you are not being serious.
>>>>>>>
>>>>>>> As you have indicated that you have recalled I corrected the error in
>>>>>>> the Linz specification that had two start states by changing one of
>>>>>>> these start states to qx.
>>>>>> Not the issue. (Though I'll note again that you don't use the notation
>>>>>> you came up with in a helpful way. There is no need for qx because it
>>>>>> could be called H.q0 or, better yet, H.0.)
>>>>>>
>>>>>>> After this I augmented the Linz notation further so that it showed the
>>>>>>> notation when the Linz Ĥ is specifically applied to the Linz ⟨Ĥ⟩ where
>>>>>>> the halt decider embedded at qx is a simulating halt decider.
>>>>>> Not the issue but if you used the . notation better this would be much clearer.
>>>>>>
>>>>>>> Since Linz does not exclude simulating halt deciders this is still the
>>>>>>> Linz Ĥ.
>>>>>>
>>>>>> You annotations are incorrect. If you'd like to know why, ask an
>>>>>> intelligent question. But why are you making any claims at all about
>>>>>> TMs that don't exist?
>>>>>
>>>>> How would you annotate all of the steps of the Linz Ĥ applied to its
>>>>> own machine description?
>>>> What new nonsense is this? No one is annotating "all of the steps" of a
>>>> TM. The annotations explain which formal statements apply in which
>>>> situations:
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* ∞ if Ĥ applied to ⟨Ĥ⟩ halts, and
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>
>>> You skipped some Linz specified states.
>> Your annotations are still wrong. Mine (in fact Linz's) are the correct
>> ones regardless of whether I (or he) includes the states you are so
>> obsessed with.
>
> As always you can dogmatically assert that I am wrong yet cannot
> provide any evidence of my error because there is in fact no error.

What would be the point in copying here what Linz says in his book
again? I have, in fact, gone through the steps from the definition of
the problem to the two lines above but it had no effect. It's right
there in the book -- the simple steps from definition

H.q0 w ⊢* H.qy if H applied to w halts, and
H.q0 w ⊢* H.qn if H applied to w does not halt,

through the construction of H' and H^ to the conclusion above. Do you
think you'd pay attention this time if I went though it all again? No,
you just want to pretend that there is no "evidence" for what I say.

>> Have another go. See if you can write the two lines about Ĥ.q0 ⟨Ĥ⟩
>> correctly with intermediate states you love so much.
>
> When the halt decider at Ĥ.qx is a simulating halt decider
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ halts, and
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt

Provided the first clause applies "if Ĥ applied to ⟨Ĥ⟩ halts", and the
second one "if Ĥ applied to ⟨Ĥ⟩ does not halt", you can add any old guff
you like. So just make sure you say something like

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
if if Ĥ applied to ⟨Ĥ⟩ halts
(and by the way, the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ halts in this case too),

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt
(and, as it happens, the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt also)

in the future. You may or may not be right about the extra guff (no one
cares), but at least you won't be hiding the truth that shows why no
such H^ exists.

>> If you post the lines with the wrong annotations again, I'll point out
>> that they are wrong again. At least you now know they are wrong.
>
> You can't point out what is wrong about them because there is nothing
> wrong about them.

They are missing the annotation that shows that no such H^ can exist.
That's quite a big error when think about it.

> This may only be a lack of comprehension on your part.

No, I suspect it's deceitfulness on your part, by there is an old Usenet
maxim: "never attribute to malice, that which can be explained by
ignorance" so I should not jump to conclusions. It could be that more
than a decade staring at a few pages in Linz, and dozens of explanations
posted here have simply not cured your ignorance on the topic.

--
Ben.

On 9/25/21 6:59 PM, olcott wrote:
> On 9/25/2021 4:54 PM, Ben Bacarisse wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> On 9/25/21 3:54 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> I derive a unique mapping from an input finite string to a Boolean
>>>>> value.
>>>>
>>>> But is it a function?  And is it a function from S* to {true, false}
>>>> (for some finite alphabet S)?  It might be, but since you only found
>>>> out
>>>> what a function is a few months ago, it's wise to ask.
>>>>
>>>> Your term "unique mapping from an input finite string to a Boolean
>>>> value" is what a coder would say.  It's not the same as a mathematician
>>>> saying "f: S* -> {true, false}".
>>>>
>>>>> 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.
>>>>
>>>>    _Bool f(char *s) { return s; }
>>>>
>>>> is a C function that maps finite strings input strings to Boolean
>>>> values.  It has no corresponding TM.
>>>
>>> Actually, you should be able to map that. The key is you need to define
>>> how you encode character strings.
>>>
>>> If the tape allows 257 values per cell, corresponding to 'no value' or
>>> the ascii values 0-255, then the test is just is the cell we start at
>>> the 'no value', which is the equivalent for a null pointer, and return
>>> false/0 if it is, else return true.
>>
>> OK, not the best example since you might consider that a natural
>> correspondence.  I'd suggest, then,
>>
>>    _Bool f(char *s) { return (uintptr_t)s & 1; }
>>
>> or
>>
>>    _Bool f(char *s) { return ((uintptr_t)s + (uintptr_t)f) & 0x8800; }
>>
>> or
>>
>>    _Bool f(char *s) { return s && *s ? f(s+1) : (uintptr_t)&s & 1; }
>>
>>> There is almost ALWAYS a 'mapping' issue of how do you plan to represent
>>> the various representations in one space to another.
>>
>> Maybe.  I think we may disagree about what a "corresponding TM" really
>> is.  But that's not the main point I was trying to make: PO's words were
>> just too vague to address why he's puzzled that something "computable"
>> in C is not "computable" by a TM.
>>
>> I agree that we can often define away the issue by being more specific.
>> The result is then a well-defined function that is can be implemented in
>> both C and realised as a TM, but lots of C code has no natural
>> corresponding TM (as I see it).
>>
>> Also, I just wanted to reiterate why C is such a terrible choice, and
>> x86 code (RDRAND, anyone?) is even worse, as a formal model of
>> computation.
>>
>
> Yes because everyone knows the carefully studying a hundreds of
> thousands of pages of execution trace is enormously easier than 14 lines
> of execution trace. The 14 lines could take many decades of study before
> understanding how the algorithm is applied whereas 500,000 pages can be
> fully understood in less than a minute.
>

But 14 lines of WRONG exection traces just plain LIE.

No x86 processor ses an unconditional call instruction and goes to a
different address than specified.