On 7/28/2021 10:36 AM, Mr Flibble wrote:
> On Tue, 27 Jul 2021 15:04:53 -0600
> Jeff Barnett <jbb@notatt.com> wrote:
>
>> On 7/27/2021 1:14 PM, olcott wrote:
>>> On 7/27/2021 2:02 PM, Peter wrote:
>>
>> <SNIP>
>>
>>> Flibble's reasoning is correct, yet based on my 2016 reasoning.
>>> When the otherwise computationally equivalent TM counter-example
>>> cases are translated into an architecture having finite resources
>>> running out of stack memory would indicate infinite recursion.
>> We just congratulated you on setting a world record in what you are
>> good at: making a mess in your head. We suggested that you retire at
>> this point and rest on your laurels but, no, you just want to extend
>> your unblemished string of nonsense.
>>
>> Lets say you try to evaluate the integer function
>> factorial(10^100000000000000000), where the argument is an integer
>> too. Now this computation runs out of stack memory and you ejaculate
>> "infinite recursion! infinite recursion!" followed by that now famous
>> remark of yours "Polly want a cracker!" Ridiculous. In a few years it
>> might not run out of stack for some definition of "a few" then we can
>> review all of this. Again.
>>
>> Have you ever stopped to think for 10 seconds before typing? You
>> wouldn't know it by what appears in this newsgroup. If I were you,
>> I'd hit the net and find a definition of factorial to parrot in your
>> next message. That would show all of us that you are still on top of
>> your game (though I really can't think of a game simple enough for
>> you to play. Any suggestions out there?) Polly want a cracker?
>
> There is no need to detect infinite recursion, merely recursion whereby
> the decider appears more than once in the call stack.
>
> This is a troll.
You, like PO, don't read. That probably wont change soon will it? I
merely responded to

"When the otherwise computationally equivalent TM counter-example cases
are translated into an architecture having finite resources running out
of stack memory would indicate infinite recursion."

If he had spent a few seconds of his "valuable" time glancing at what he
typed before sending, he might have said what you did. Well it seems
that you didn't read what he said either.

Perhaps you two can take your dialogue offline. No one will miss it and
you can set your own ground rules to foster miscommunications.
--
Jeff Barnett

On 7/28/2021 12:40 PM, Jeff Barnett wrote:
> On 7/28/2021 10:36 AM, Mr Flibble wrote:
>> On Tue, 27 Jul 2021 15:04:53 -0600
>> Jeff Barnett <jbb@notatt.com> wrote:
>>
>>> On 7/27/2021 1:14 PM, olcott wrote:
>>>> On 7/27/2021 2:02 PM, Peter wrote:
>>>
>>> <SNIP>
>>>
>>>> Flibble's reasoning is correct, yet based on my 2016 reasoning.
>>>> When the otherwise computationally equivalent TM counter-example
>>>> cases are translated into an architecture having finite resources
>>>> running out of stack memory would indicate infinite recursion.
>>> We just congratulated you on setting a world record in what you are
>>> good at: making a mess in your head. We suggested that you retire at
>>> this point and rest on your laurels but, no, you just want to extend
>>> your unblemished string of nonsense.
>>>
>>> Lets say you try to evaluate the integer function
>>> factorial(10^100000000000000000), where the argument is an integer
>>> too. Now this computation runs out of stack memory and you ejaculate
>>> "infinite recursion! infinite recursion!" followed by that now famous
>>> remark of yours "Polly want a cracker!" Ridiculous. In a few years it
>>> might not run out of stack for some definition of "a few" then we can
>>> review all of this. Again.
>>>
>>> Have you ever stopped to think for 10 seconds before typing? You
>>> wouldn't know it by what appears in this newsgroup. If I were you,
>>> I'd hit the net and find a definition of factorial to parrot in your
>>> next message. That would show all of us that you are still on top of
>>> your game (though I really can't think of a game simple enough for
>>> you to play. Any suggestions out there?) Polly want a cracker?
>>
>> There is no need to detect infinite recursion, merely recursion whereby
>> the decider appears more than once in the call stack.
>>
>> This is a troll.
> You, like PO, don't read. That probably wont change soon will it? I
> merely responded to
>
> "When the otherwise computationally equivalent TM counter-example cases
> are translated into an architecture having finite resources running out
> of stack memory would indicate infinite recursion."
>

void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
}

My above words apply to this case where more than two recursive
invocations prove that infinite invocations exist.

It is more correct to do as I do and verify that the sequence of nested
recursive inovocations has no termination condition in the execution
trace of the code that is being examined.

While H remains in pure simulation mode the input to H(P,P) cannot
possibly ever reach its final state. This unequivocally proves that the
input to H(P,P) never halts.

> If he had spent a few seconds of his "valuable" time glancing at what he
> typed before sending, he might have said what you did. Well it seems
> that you didn't read what he said either.
>
> Perhaps you two can take your dialogue offline. No one will miss it and
> you can set your own ground rules to foster miscommunications.

--
Copyright 2021 Pete Olcott

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

On 7/28/21 10:53 AM, olcott wrote:
> On 7/28/2021 12:40 PM, Jeff Barnett wrote:
>> On 7/28/2021 10:36 AM, Mr Flibble wrote:
>>> On Tue, 27 Jul 2021 15:04:53 -0600
>>> Jeff Barnett <jbb@notatt.com> wrote:
>>>
>>>> On 7/27/2021 1:14 PM, olcott wrote:
>>>>> On 7/27/2021 2:02 PM, Peter wrote:
>>>>
>>>> <SNIP>
>>>>
>>>>> Flibble's reasoning is correct, yet based on my 2016 reasoning.
>>>>> When the otherwise computationally equivalent TM counter-example
>>>>> cases are translated into an architecture having finite resources
>>>>> running out of stack memory would indicate infinite recursion.
>>>> We just congratulated you on setting a world record in what you are
>>>> good at: making a mess in your head. We suggested that you retire at
>>>> this point and rest on your laurels but, no, you just want to extend
>>>> your unblemished string of nonsense.
>>>>
>>>> Lets say you try to evaluate the integer function
>>>> factorial(10^100000000000000000), where the argument is an integer
>>>> too. Now this computation runs out of stack memory and you ejaculate
>>>> "infinite recursion! infinite recursion!" followed by that now famous
>>>> remark of yours "Polly want a cracker!" Ridiculous. In a few years it
>>>> might not run out of stack for some definition of "a few" then we can
>>>> review all of this. Again.
>>>>
>>>> Have you ever stopped to think for 10 seconds before typing? You
>>>> wouldn't know it by what appears in this newsgroup. If I were you,
>>>> I'd hit the net and find a definition of factorial to parrot in your
>>>> next message. That would show all of us that you are still on top of
>>>> your game (though I really can't think of a game simple enough for
>>>> you to play. Any suggestions out there?) Polly want a cracker?
>>>
>>> There is no need to detect infinite recursion, merely recursion whereby
>>> the decider appears more than once in the call stack.
>>>
>>> This is a troll.
>> You, like PO, don't read. That probably wont change soon will it? I
>> merely responded to
>>
>> "When the otherwise computationally equivalent TM counter-example
>> cases are translated into an architecture having finite resources
>> running out of stack memory would indicate infinite recursion."
>>
>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
> }
>
> My above words apply to this case where more than two recursive
> invocations prove that infinite invocations exist.
>

Except that the fact that any H that is capable of answering H(P,P) WILL
abort the simulation at some point, means that for THIS H, its P will
NOT hve infinite invocations. if the H doesn't abort its simulation, it
will never return an answer to H(P,P) and thus start off as incorrect.

You neglect that the behavior of P is dependent on the algorithm of H.
This leads to UNSOUND logic.

> It is more correct to do as I do and verify that the sequence of nested
> recursive inovocations has no termination condition in the execution
> trace of the code that is being examined.

But it does, in the aborting action of the H that the previous P uses,
which you erroniously ignore.
>
> While H remains in pure simulation mode the input to H(P,P) cannot
> possibly ever reach its final state. This unequivocally proves that the
> input to H(P,P) never halts.
>

But if it EVER leaves that mode, then you can not apply the
transformation you do, so all you have proved is that P(P) is
non-halting for an H that ALWAYS REMAINS in pure simulation mode, and
those H never will return an answer for H(P,P) so are wrong.

Again, you neglect that the behavior of P is a function of the
algorithm/behavior of H so you perform an invalid analysis.