On 9/25/2021 6:33 PM, Ben Bacarisse wrote:
> 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.
>

Every time that anyone points to any "error" in what I have said it is
always a dishonest dodge strawman error.

The issue that my C code might not correspond to a TM computation is the
only issue that remains open.

--
Copyright 2021 Pete Olcott

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

On 9/25/2021 6:55 PM, Ben Bacarisse wrote:
> 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
>

That is not what it says and that is not what Linz says.

The halt decider is only at state Ĥ.qx and is only applied to two copies
of the TM description of Ĥ it cannot be applied to Ĥ itself, the input
must be a TM description and not a TM.

When the halt decider at Ĥ is a simulating halt decider then it
transitions to Ĥ.qn on the basis that the simulation of its first TM
description ⟨Ĥ⟩ applied to its second TM description ⟨Ĥ⟩ never reaches
its final state whether or not the simulating halt decider at Ĥ.qx ever
stops simulating this input.

--
Copyright 2021 Pete Olcott

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

On 9/25/2021 8:18 PM, Richard Damon wrote:
> 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.
>

Yes the fact that a simulating halt decider can ignore its own execution
trace while it is only simulating its input has always been over your
head. That it is over your head does not mean that I am wrong.

--
Copyright 2021 Pete Olcott

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

On 9/25/2021 5:14 PM, Richard Damon wrote:
> 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.
>

Now that I am deriving my alternative halt deciding algorithm it is
coming into sharp focus exactly how static local data can make C code
not a pure function of its inputs.

The good news about this newest understanding is that it validates my
updated algorithm design. It looks like I may be able to exactly
duplicate the Linz proof as an actual pure function of its inputs.

It it currently looking like I can do this relatively quickly.
The reason that I created the whole x86utm operating system was so that
major overhauls of my halt decider would be very easy at the C level.

Some of your feedback has been very good. If I made a RASP machine I
would make an x86 to RASP translator, this way I could still write the
code in C.

--
Copyright 2021 Pete Olcott

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

On 9/25/21 11:00 PM, olcott wrote:
> On 9/25/2021 6:55 PM, Ben Bacarisse wrote:
>> 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
>>
>
> That is not what it says and that is not what Linz says.
>
> The halt decider is only at state Ĥ.qx and is only applied to two copies
> of the TM description of Ĥ it cannot be applied to Ĥ itself, the input
> must be a TM description and not a TM.

The Halt Decider is not ONLY at state H^.qx, it is also a fully
indepenent machine, so is there not only one copy of its instruction
present at H^.qx to H^.qn and H^.qy but there is another copy present in
the machine H.q0 to H.qn and H.qy.

>
> When the halt decider at Ĥ is a simulating halt decider then it
> transitions to Ĥ.qn on the basis that the simulation of its first TM
> description ⟨Ĥ⟩ applied to its second TM description ⟨Ĥ⟩ never reaches
> its final state whether or not the simulating halt decider at Ĥ.qx ever
> stops simulating this input.
>
>

IF H^ never gets to the state H^.qn, given it got to H^.qx with the
input tape containing <H^> <H^> then that means that the other copy of H
as an indpendent machine given in;ut <H^> <H^> will ALSO not reach its
H.qn state, and thus has failed to be a decider.

By the definition of construction, both the machines at H^.qx and H.q0
have the exact same instruction sequence (unless we reach the qy state)
and the tape of the two machines is exactly the same, so they will do
the exact same sequence of steps and arrive at the exact same result.

On 9/25/21 10:45 PM, olcott wrote:
> On 9/25/2021 6:33 PM, Ben Bacarisse wrote:
>> 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.
>>
>
> Every time that anyone points to any "error" in what I have said it is
> always a dishonest dodge strawman error.

FALSE. LIAR.

Youc call anything that points out errors to be dishonest dodges.

>
> The issue that my C code might not correspond to a TM computation is the
> only issue that remains open.
>

Wrong, but if you do make your Halt Decider an actual computation you
will see things much clearer.

On 9/25/21 11:03 PM, olcott wrote:
> On 9/25/2021 8:18 PM, Richard Damon wrote:
>> 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.
>>
>
> Yes the fact that a simulating halt decider can ignore its own execution
> trace while it is only simulating its input has always been over your
> head. That it is over your head does not mean that I am wrong.
>
>

But you state it wrong. A simulating Halt Decider can NOT ignore the
effect of other copies of itself. That is fundamental garbage.

You have NOT 'proved' that.

A big part of the issue is that your H doesn't 'ignore' the behavior of
the other copies, but PRESUMES the behavior, and it presumes wrong.

If H actually 'ignored' the behavior or H, then it would just ignore
what happens when P calls H(P,P) but then it doesn't have anything to do
and just needs to guess.

Instead, H just assumes that copies of H will be pure simulators of the
input (and pure simulators forever, NEVER aborting). This is a false
assumption. leading to UNSOUND logic and wrong answers.

olcott <NoOne@NoWhere.com> writes:

> Now that I am deriving my alternative halt deciding algorithm it is
> coming into sharp focus exactly how static local data can make C code
> not a pure function of its inputs.

You could have asked pretty much any programmer and they would have
explained it to you.

--
Ben.

olcott <NoOne@NoWhere.com> writes:

> On 9/25/2021 6:33 PM, Ben Bacarisse wrote:
>> 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.
>
> Every time that anyone points to any "error" in what I have said it is
> always a dishonest dodge strawman error.

I would not call that remark pointing out an error. Pointing out an
error would look like this: Your "halt decider" returns false for an
input that represents a computation that halts. That computation "only
halts because ... <reason>" but it halts none the less. You've been
quite clear about this. These facts -- that the decider return false,
and the fact that computation being assessed halts (for some reason no
one but you cares about) -- come from you:

"Halts(Confound_Halts, Confound_Halts) returns false."
Message-ID: <2aidnV9e3qQaOCDCnZ2dnUU7-c3NnZ2d@giganews.com>

and

"The input to Halts is only finite because..."
Message-ID: <6eSdnYuLBrIuVFzCnZ2dnUU7-cPNnZ2d@giganews.com>

This is what I call "pointing out an error" -- explaining it a citing
the evidence, which in this case has to come from you because you are
still hiding your code. I must say it is surprising how clearly you
have laid out what you are doing wrong given that you've invested so
much effort in keeping the code secret.

> The issue that my C code might not correspond to a TM computation is
> the only issue that remains open.

That and being wrong about the answer. Or have you changed your mind
about declaring false to be the right answer is for computations that
halt in some special way?

This was all very clear at some stage but maybe you can see the futility
in that approach and want H(P, I) to be true iff P(I) halts. That would
be a novel tactic for you -- to address the actual halting problem.

--
Ben.

olcott <NoOne@NoWhere.com> writes:

> On 9/25/2021 6:55 PM, Ben Bacarisse wrote:
>> 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
>
> That is not what it says and that is not what Linz says.

To what does "that" refer? I used your notation, but I cited Linz
correctly. Please promise to do so in future. You must state Linz's
annotation for the behaviour of Ĥ because Ĥ is Linz's Ĥ though feel free
to add your junk text. We can safely ignore it if you keep the correct
annotations in place.

(I was tempted just to reply "liar" but I think you really don't know
what Linz wrote even after decades of studying two and half pages.)

> The halt decider is only at state Ĥ.qx and is only applied to two
> copies of the TM description of Ĥ it cannot be applied to Ĥ itself,
> the input must be a TM description and not a TM.

Yes, it seems you still don't understand what Linz wrote. Amazing. I
can explain why Linz correctly says what he says, but I don't think
you'd be able to follow it. You don't know how to be a student.

--
Ben.