... due to the infinite recursion missed by Strachey blowing the stack of
any turing machine simulator with finite memory (stack) size. One
simply needs to detect out of memory when more than one instance of the
decider is present in the call stack.

This is a troll.

Message ends.

/Flibble

On 7/27/2021 12:34 PM, Mr Flibble wrote:
> .. due to the infinite recursion missed by Strachey blowing the stack of
> any turing machine simulator with finite memory (stack) size. One
> simply needs to detect out of memory when more than one instance of the
> decider is present in the call stack.
>

This seems correct. I accomplished the same thing differently in my
current paper.

To the best of my knowledge I am the first to derive the key insight
that the conventional HP counter-examples specify infinite recursion to
any simulating halt decider.

It looks like the original specification provided in
the Linz text may be infinitely recursive in that each
TM requires its own input. ...(Olcott:2016)

https://www.researchgate.net/publication/307509556_Self_Modifying_Turing_Machine_SMTM_Solution_to_the_Halting_Problem_concrete_example

> This is a troll.
>
> Message ends.
>
> /Flibble
>

This is my current paper:
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

--
Copyright 2021 Pete Olcott

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

Mr Flibble wrote:
> .. due to the infinite recursion missed by Strachey blowing the stack of
> any turing machine simulator with finite memory (stack) size. One

Turing machines don't have stacks. Stack machines have (of course)
stacks of limitless length.

> simply needs to detect out of memory when more than one instance of the
> decider is present in the call stack.
>
> This is a troll.
>
> Message ends.
>
> /Flibble
>

--
The world will little note, nor long remember what we say here
Abraham Lincoln at Gettysburg

On 7/27/2021 2:02 PM, Peter wrote:
> Mr Flibble wrote:
>> .. due to the infinite recursion missed by Strachey blowing the stack of
>> any turing machine simulator with finite memory (stack) size.  One
>
> Turing machines don't have stacks.  Stack machines have (of course)
> stacks of limitless length.
>

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.

>> simply needs to detect out of memory when more than one instance of the
>> decider is present in the call stack.
>>
>> This is a troll.
>>
>> Message ends.
>>
>> /Flibble
>>
>
>

--
Copyright 2021 Pete Olcott

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

On 7/27/2021 12:14 PM, olcott wrote:
> On 7/27/2021 2:02 PM, Peter wrote:
>> Mr Flibble wrote:
>>> .. due to the infinite recursion missed by Strachey blowing the stack of
>>> any turing machine simulator with finite memory (stack) size.  One
>>
>> Turing machines don't have stacks.  Stack machines have (of course)
>> stacks of limitless length.
>>
>
> 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.
>
>>> simply needs to detect out of memory when more than one instance of the
>>> decider is present in the call stack.
>>>

>>> This is a troll.
^^^^^^^^^^^^^^^^^^^^^^^^^

On 7/27/2021 2:23 PM, Chris M. Thomasson wrote:
> On 7/27/2021 12:14 PM, olcott wrote:
>> On 7/27/2021 2:02 PM, Peter wrote:
>>> Mr Flibble wrote:
>>>> .. due to the infinite recursion missed by Strachey blowing the
>>>> stack of
>>>> any turing machine simulator with finite memory (stack) size.  One
>>>
>>> Turing machines don't have stacks.  Stack machines have (of course)
>>> stacks of limitless length.
>>>
>>
>> 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.
>>
>>>> simply needs to detect out of memory when more than one instance of the
>>>> decider is present in the call stack.
>>>>
>
>
>>>> This is a troll.
> ^^^^^^^^^^^^^^^^^^^^^^^^^

And likewise I am only kidding when I say that 2 + 3 = 5.
Correct reasoning remains correct no matter how it is mislabeled.

--
Copyright 2021 Pete Olcott

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

olcott wrote:
> On 7/27/2021 2:02 PM, Peter wrote:
>> Mr Flibble wrote:
>>> .. due to the infinite recursion missed by Strachey blowing the stack of
>>> any turing machine simulator with finite memory (stack) size.  One
>>
>> Turing machines don't have stacks.  Stack machines have (of course)
>> stacks of limitless length.
>>
>
> 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.

The machines of interest can't run out of stack. Some of them (TMs)
don't have stacks to run out of, and others (e.g. stack machines) have
limitless stacks.
>
>>> simply needs to detect out of memory when more than one instance of the
>>> decider is present in the call stack.
>>>
>>> This is a troll.
>>>
>>> Message ends.
>>>
>>> /Flibble
>>>
>>
>>
>
>

--
The world will little note, nor long remember what we say here
Abraham Lincoln at Gettysburg

On Tue, 27 Jul 2021 14:14:20 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/27/2021 2:02 PM, Peter wrote:
> > Mr Flibble wrote:
> >> .. due to the infinite recursion missed by Strachey blowing the
> >> stack of any turing machine simulator with finite memory (stack)
> >> size.  One
> >
> > Turing machines don't have stacks.  Stack machines have (of course)
> > stacks of limitless length.
> >
>
> Flibble's reasoning is correct, yet based on my 2016 reasoning.

It is based on my own reasoning not yours, dear.

/Flibble

On 2021-07-27 13:14, olcott wrote:
> On 7/27/2021 2:02 PM, Peter wrote:
>> Mr Flibble wrote:
>>> .. due to the infinite recursion missed by Strachey blowing the stack of
>>> any turing machine simulator with finite memory (stack) size.  One
>>
>> Turing machines don't have stacks.  Stack machines have (of course)
>> stacks of limitless length.
>>
>
> 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.

No it wouldn't. One can easily envision calculations which require
enormous amounts of stack space (more than any current computer) yet are
still finite.

Consider a recursive implementation of the factorial function which
accepts and returns unbounded integers (i.e strings of hexadecimal
digits of unlimited length). Do you think that
Factorial(Factorial(Factorial 123456789))) would have sufficient stack
space? Probably not, but it is still finite.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 7/27/21 12:14 PM, olcott wrote:
> On 7/27/2021 2:02 PM, Peter wrote:
>> Mr Flibble wrote:
>>> .. due to the infinite recursion missed by Strachey blowing the stack of
>>> any turing machine simulator with finite memory (stack) size.  One
>>
>> Turing machines don't have stacks.  Stack machines have (of course)
>> stacks of limitless length.
>>
>
> 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.
No, that is incorrect. You can make a truly finite machine that exceeds
the capability of your finite machine. Thus it is incorrect to say that
any machine that exceeds your memory is infinite.

You CAN argue that as long as your machine doesn't run out of memory you
are equivalent, but if you do, you have lost that claim.

Note, that this ALSO requires that your finite equivalents actually are
equivalent, which your current system isn't, but so far it hasn't been
worth fighting that too much.

You WILL need to fix that to make the proof more formal, which will kill
your currect test for recursion.

>
>>> simply needs to detect out of memory when more than one instance of the
>>> decider is present in the call stack.
>>>
>>> This is a troll.
>>>
>>> Message ends.
>>>
>>> /Flibble
>>>
>>
>>
>
>

On 7/27/2021 1:05 PM, Richard Damon wrote:
> On 7/27/21 12:14 PM, olcott wrote:
>> On 7/27/2021 2:02 PM, Peter wrote:
>>> Mr Flibble wrote:
>>>> .. due to the infinite recursion missed by Strachey blowing the stack of
>>>> any turing machine simulator with finite memory (stack) size.  One
>>>
>>> Turing machines don't have stacks.  Stack machines have (of course)
>>> stacks of limitless length.
>>>
>>
>> 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.
> No, that is incorrect. You can make a truly finite machine that exceeds
> the capability of your finite machine. Thus it is incorrect to say that
> any machine that exceeds your memory is infinite.

[...]
Blowing up the stack, or running out of memory is not good enough. An
infinite process can simple take TRNG bits and display them for ever,
and ever, and ever... It will never run out of memory.

;^)

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?
--
Jeff Barnett

On 7/27/2021 2:47 PM, Mr Flibble wrote:
> On Tue, 27 Jul 2021 14:14:20 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 7/27/2021 2:02 PM, Peter wrote:
>>> Mr Flibble wrote:
>>>> .. due to the infinite recursion missed by Strachey blowing the
>>>> stack of any turing machine simulator with finite memory (stack)
>>>> size.  One
>>>
>>> Turing machines don't have stacks.  Stack machines have (of course)
>>> stacks of limitless length.
>>>
>>
>> Flibble's reasoning is correct, yet based on my 2016 reasoning.
>
> It is based on my own reasoning not yours, dear.
>
> /Flibble
>

It is documented that I came up with the idea of infinitely nested
recursion/simulation in 2016. I have posted this idea very extensively
in this forum long before you even understood the nature of the halting
problem proofs.

It looks like the original specification provided
in the Linz text may be infinitely recursive in
that each TM requires its own input.

https://www.researchgate.net/publication/307509556_Self_Modifying_Turing_Machine_SMTM_Solution_to_the_Halting_Problem_concrete_example

It was shortly before you posted this message that you showed that you
understood the difference between refuting the halting problem proofs
and solving the halting problem.

On 7/10/2021 12:00 PM, Mr Flibble wrote:
> I agree with Olcott that a halt decider can NOT be part of that which
> is being decided (see [Strachey 1965]) which, if Olcott is correct,
> falsifies a collection of proofs (which I don't have the time to
> examine) which rely on that mistake. >
> /Flibble
>

Prior to this there was no indication that you understood the mechanism
of the conventional proofs at all. After this you proved that you
understood this mechanism far better that most everyone else.

--
Copyright 2021 Pete Olcott

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

On 7/27/2021 4:04 PM, Jeff Barnett 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.

Oh one who has wit of comparable magnitude to a nit:

Your reference is not to the specific case at hand:

rec routine P
§L:if T[P] go to L
Return §

Strachey, C 1965. An impossible program The Computer Journal, Volume 7,
Issue 4, January 1965, Page 313, https://doi.org/10.1093/comjnl/7.4.313

For the specific case at hand Flibble's crude system of infinite
recursion detection would work.

*nit noun*
1: the egg of a louse or other parasitic insect
also : the insect itself when young
https://www.merriam-webster.com/dictionary/nit

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

--
Copyright 2021 Pete Olcott

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

On 7/27/2021 2:58 PM, André G. Isaak wrote:
> On 2021-07-27 13:14, olcott wrote:
>> On 7/27/2021 2:02 PM, Peter wrote:
>>> Mr Flibble wrote:
>>>> .. due to the infinite recursion missed by Strachey blowing the
>>>> stack of
>>>> any turing machine simulator with finite memory (stack) size.  One
>>>
>>> Turing machines don't have stacks.  Stack machines have (of course)
>>> stacks of limitless length.
>>>
>>
>> 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.
>
> No it wouldn't. One can easily envision calculations which require
> enormous amounts of stack space (more than any current computer) yet are
> still finite.
>

Your reference is not to the specific case at hand:

rec routine P
§L:if T[P] go to L
Return §

Strachey, C 1965. An impossible program The Computer Journal, Volume 7,
Issue 4, January 1965, Page 313, https://doi.org/10.1093/comjnl/7.4.313

For the specific case at hand Flibble's crude system of infinite
recursion detection would work.

> Consider a recursive implementation of the factorial function which
> accepts and returns unbounded integers (i.e strings of hexadecimal
> digits of unlimited length). Do you think that
> Factorial(Factorial(Factorial 123456789))) would have sufficient stack
> space? Probably not, but it is still finite.
>
> André
>

--
Copyright 2021 Pete Olcott

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

On 7/27/2021 2:46 PM, Peter wrote:
> olcott wrote:
>> On 7/27/2021 2:02 PM, Peter wrote:
>>> Mr Flibble wrote:
>>>> .. due to the infinite recursion missed by Strachey blowing the
>>>> stack of
>>>> any turing machine simulator with finite memory (stack) size.  One
>>>
>>> Turing machines don't have stacks.  Stack machines have (of course)
>>> stacks of limitless length.
>>>
>>
>> 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.
>
> The machines of interest can't run out of stack.  Some of them (TMs)
> don't have stacks to run out of, and others (e.g. stack machines) have
> limitless stacks.

Your reference is not to the specific case at hand:

rec routine P
§L:if T[P] go to L
Return §

Strachey, C 1965. An impossible program The Computer Journal, Volume 7,
Issue 4, January 1965, Page 313, https://doi.org/10.1093/comjnl/7.4.313

For the specific case at hand Flibble's crude system of infinite
recursion detection would work.

>>
>>>> simply needs to detect out of memory when more than one instance of the
>>>> decider is present in the call stack.
>>>>
>>>> This is a troll.
>>>>
>>>> Message ends.
>>>>
>>>> /Flibble
>>>>
>>>
>>>
>>
>>
>
>

--
Copyright 2021 Pete Olcott

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

On 7/27/21 3:13 PM, olcott wrote:
> On 7/27/2021 2:46 PM, Peter wrote:
>> olcott wrote:
>>> On 7/27/2021 2:02 PM, Peter wrote:
>>>> Mr Flibble wrote:
>>>>> .. due to the infinite recursion missed by Strachey blowing the
>>>>> stack of
>>>>> any turing machine simulator with finite memory (stack) size.  One
>>>>
>>>> Turing machines don't have stacks.  Stack machines have (of course)
>>>> stacks of limitless length.
>>>>
>>>
>>> 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.
>>
>> The machines of interest can't run out of stack.  Some of them (TMs)
>> don't have stacks to run out of, and others (e.g. stack machines) have
>> limitless stacks.
>
> Your reference is not to the specific case at hand:
>
> rec routine P
>   §L:if T[P] go to L
>     Return §
>
> Strachey, C 1965.  An impossible program The Computer Journal, Volume 7,
> Issue 4, January 1965, Page 313, https://doi.org/10.1093/comjnl/7.4.313
>
> For the specific case at hand Flibble's crude system of infinite
> recursion detection would work.

It would still fail.

When we run P(P), that machine will call H(P,P) which will cycle through
some large number of iterations, see the exhaustion of memory, say that
the machine is non-halting, return that value, and P will then Halt,
show that H was WRONG. DEFINITION.

You STILL have the case that replacement of the simulation of a
simulator by the simulation of the machine being simulated is only valid
if the simulator NEVER, (and that meaans NEVER) aborts its simulation.

Note, this method actually breaks the definition of computation, as the
results of a given machine isn't just dependent on the defintion of THAT
computation, as it becomes dependent on how much else is happening.

At best, the system needs to just abort the whole machine and say that
the computation exceeds the capability of the system. This means that H
can't use it as its decision method.

On 7/27/2021 5:56 PM, Richard Damon wrote:
> On 7/27/21 3:13 PM, olcott wrote:
>> On 7/27/2021 2:46 PM, Peter wrote:
>>> olcott wrote:
>>>> On 7/27/2021 2:02 PM, Peter wrote:
>>>>> Mr Flibble wrote:
>>>>>> .. due to the infinite recursion missed by Strachey blowing the
>>>>>> stack of
>>>>>> any turing machine simulator with finite memory (stack) size.  One
>>>>>
>>>>> Turing machines don't have stacks.  Stack machines have (of course)
>>>>> stacks of limitless length.
>>>>>
>>>>
>>>> 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.
>>>
>>> The machines of interest can't run out of stack.  Some of them (TMs)
>>> don't have stacks to run out of, and others (e.g. stack machines) have
>>> limitless stacks.
>>
>> Your reference is not to the specific case at hand:
>>
>> rec routine P
>>   §L:if T[P] go to L
>>     Return §
>>
>> Strachey, C 1965.  An impossible program The Computer Journal, Volume 7,
>> Issue 4, January 1965, Page 313, https://doi.org/10.1093/comjnl/7.4.313
>>
>> For the specific case at hand Flibble's crude system of infinite
>> recursion detection would work.
>
> It would still fail.
>
> When we run P(P), that machine will call H(P,P) which will cycle through
> some large number of iterations, see the exhaustion of memory, say that
> the machine is non-halting, return that value, and P will then Halt,
> show that H was WRONG. DEFINITION.

Thanks to André for pointing out that the key element of halting is
reaching the final state of a computation we can easily toss out your
drivel for what it is.

YOU ARE USING THE WRONG FREAKING DEFINITION

--
Copyright 2021 Pete Olcott

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

On 7/27/21 4:06 PM, olcott wrote:
> On 7/27/2021 5:56 PM, Richard Damon wrote:
>> On 7/27/21 3:13 PM, olcott wrote:
>>> On 7/27/2021 2:46 PM, Peter wrote:
>>>> olcott wrote:
>>>>> On 7/27/2021 2:02 PM, Peter wrote:
>>>>>> Mr Flibble wrote:
>>>>>>> .. due to the infinite recursion missed by Strachey blowing the
>>>>>>> stack of
>>>>>>> any turing machine simulator with finite memory (stack) size.  One
>>>>>>
>>>>>> Turing machines don't have stacks.  Stack machines have (of course)
>>>>>> stacks of limitless length.
>>>>>>
>>>>>
>>>>> 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.
>>>>
>>>> The machines of interest can't run out of stack.  Some of them (TMs)
>>>> don't have stacks to run out of, and others (e.g. stack machines) have
>>>> limitless stacks.
>>>
>>> Your reference is not to the specific case at hand:
>>>
>>> rec routine P
>>>    §L:if T[P] go to L
>>>      Return §
>>>
>>> Strachey, C 1965.  An impossible program The Computer Journal, Volume 7,
>>> Issue 4, January 1965, Page 313, https://doi.org/10.1093/comjnl/7.4.313
>>>
>>> For the specific case at hand Flibble's crude system of infinite
>>> recursion detection would work.
>>
>> It would still fail.
>>
>> When we run P(P), that machine will call H(P,P) which will cycle through
>> some large number of iterations, see the exhaustion of memory, say that
>> the machine is non-halting, return that value, and P will then Halt,
>> show that H was WRONG. DEFINITION.
>
> Thanks to André for pointing out that the key element of halting is
> reaching the final state of a computation we can easily toss out your
> drivel for what it is.
>
> YOU ARE USING THE WRONG FREAKING DEFINITION
>

The DEFINITION of what answer the Halting Decider is supposed to produce
to be right is what the Halting result of running the machine/input that
is given to the decider as a representation.

The DEFINITION of if that Machine Halted or not is does it reach its
final Halting State in a finite number of steps or not.

We Run P(P), and it will call H(P,P) and that will run for some long but
finite number of steps simulating many levels, and eventually run out of
'stack' and then that H will abort its simulation and return its
non-halting answer, and then that P that it returned to will reach its
final halting state and thus show that P(P) is a Halting Machine.

By the definition of a Halting Decider, that IS the right answer that H
needs to return.

Thus, the right answer for the question give by H(P,P) is determined by
does P(P) reach its final halting state, which it DOES, so the right
answer is HALTING, but the answer that H gave was non-halting, so it was
WRONG.

What wrong definition is being used?

Be clear.

You seem to be Lying, again.

On 7/27/2021 3:56 PM, olcott wrote:
> On 7/27/2021 4:04 PM, Jeff Barnett 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.
>
> Oh one who has wit of comparable magnitude to a nit:
>
> Your reference is not to the specific case at hand:
>
> rec routine P
>   §L:if T[P] go to L
>     Return §
>
> Strachey, C 1965.  An impossible program The Computer Journal, Volume 7,
> Issue 4, January 1965, Page 313, https://doi.org/10.1093/comjnl/7.4.313
>
> For the specific case at hand Flibble's crude system of infinite
> recursion detection would work.
>
>
>
> *nit noun*
> 1: the egg of a louse or other parasitic insect
> also : the insect itself when young
> https://www.merriam-webster.com/dictionary/nit

I see mow you are picking nits. That activity is dangerous to your
health. If you become infected, they make a special soap. In addition to
your hair, see if you can get some into the cranial cavity and wash the
nonsense out of your purported brain.

>> 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?
You couldn't even pause for the suggested 10 seconds. It must really
hurt to be you.
--
Jeff Barnett

On 7/28/2021 1:44 AM, Jeff Barnett wrote:
> On 7/27/2021 3:56 PM, olcott wrote:
>> On 7/27/2021 4:04 PM, Jeff Barnett 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.
>>
>> Oh one who has wit of comparable magnitude to a nit:
>>
>> Your reference is not to the specific case at hand:
>>
>> rec routine P
>>    §L:if T[P] go to L
>>      Return §
>>
>> Strachey, C 1965.  An impossible program The Computer Journal, Volume
>> 7, Issue 4, January 1965, Page 313,
>> https://doi.org/10.1093/comjnl/7.4.313
>>
>> For the specific case at hand Flibble's crude system of infinite
>> recursion detection would work.
>>
>>
>>
>> *nit noun*
>> 1: the egg of a louse or other parasitic insect
>> also : the insect itself when young
>> https://www.merriam-webster.com/dictionary/nit
>
> I see mow you are picking nits. That activity is dangerous to your
> health. If you become infected, they make a special soap. In addition to
> your hair, see if you can get some into the cranial cavity and wash the
> nonsense out of your purported brain.
>
>>> 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?
> You couldn't even pause for the suggested 10 seconds. It must really
> hurt to be you.

So you are not smart enough to realize that I called you a nitwit.
>> Oh one who has wit of comparable magnitude to a nit:

--
Copyright 2021 Pete Olcott

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

On Tue, 27 Jul 2021 16:06:09 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/27/2021 2:47 PM, Mr Flibble wrote:
> > On Tue, 27 Jul 2021 14:14:20 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 7/27/2021 2:02 PM, Peter wrote:
> >>> Mr Flibble wrote:
> >>>> .. due to the infinite recursion missed by Strachey blowing the
> >>>> stack of any turing machine simulator with finite memory (stack)
> >>>> size.  One
> >>>
> >>> Turing machines don't have stacks.  Stack machines have (of
> >>> course) stacks of limitless length.
> >>>
> >>
> >> Flibble's reasoning is correct, yet based on my 2016 reasoning.
> >
> > It is based on my own reasoning not yours, dear.
> >
> > /Flibble
> >
>
> It is documented that I came up with the idea of infinitely nested
> recursion/simulation in 2016. I have posted this idea very
> extensively in this forum long before you even understood the nature
> of the halting problem proofs.
>
> It looks like the original specification provided
> in the Linz text may be infinitely recursive in
> that each TM requires its own input.
>
> https://www.researchgate.net/publication/307509556_Self_Modifying_Turing_Machine_SMTM_Solution_to_the_Halting_Problem_concrete_example
>
>
> It was shortly before you posted this message that you showed that
> you understood the difference between refuting the halting problem
> proofs and solving the halting problem.
>
> On 7/10/2021 12:00 PM, Mr Flibble wrote:
> > I agree with Olcott that a halt decider can NOT be part of that
> > which is being decided (see [Strachey 1965]) which, if Olcott is
> > correct, falsifies a collection of proofs (which I don't have the
> > time to examine) which rely on that mistake. >
> > /Flibble
> >
>
> Prior to this there was no indication that you understood the
> mechanism of the conventional proofs at all. After this you proved
> that you understood this mechanism far better that most everyone else.
Two people can arrive at the same conclusion independently you know. I
pointed out to you that [Strachey 1965] was pathological/erroneous due
to the decider being part of or called by that which is being decided
(P) which gives arise to a necessarily tri-state decision result with
the third result state being that P is invalid.

/Flibble

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.

/Flibble

On 7/28/2021 11:35 AM, Mr Flibble wrote:
> On Tue, 27 Jul 2021 16:06:09 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 7/27/2021 2:47 PM, Mr Flibble wrote:
>>> On Tue, 27 Jul 2021 14:14:20 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 7/27/2021 2:02 PM, Peter wrote:
>>>>> Mr Flibble wrote:
>>>>>> .. due to the infinite recursion missed by Strachey blowing the
>>>>>> stack of any turing machine simulator with finite memory (stack)
>>>>>> size.  One
>>>>>
>>>>> Turing machines don't have stacks.  Stack machines have (of
>>>>> course) stacks of limitless length.
>>>>>
>>>>
>>>> Flibble's reasoning is correct, yet based on my 2016 reasoning.
>>>
>>> It is based on my own reasoning not yours, dear.
>>>
>>> /Flibble
>>>
>>
>> It is documented that I came up with the idea of infinitely nested
>> recursion/simulation in 2016. I have posted this idea very
>> extensively in this forum long before you even understood the nature
>> of the halting problem proofs.
>>
>> It looks like the original specification provided
>> in the Linz text may be infinitely recursive in
>> that each TM requires its own input.
>>
>> https://www.researchgate.net/publication/307509556_Self_Modifying_Turing_Machine_SMTM_Solution_to_the_Halting_Problem_concrete_example
>>
>>
>> It was shortly before you posted this message that you showed that
>> you understood the difference between refuting the halting problem
>> proofs and solving the halting problem.
>>
>> On 7/10/2021 12:00 PM, Mr Flibble wrote:
>> > I agree with Olcott that a halt decider can NOT be part of that
>> > which is being decided (see [Strachey 1965]) which, if Olcott is
>> > correct, falsifies a collection of proofs (which I don't have the
>> > time to examine) which rely on that mistake. >
>> > /Flibble
>> >
>>
>> Prior to this there was no indication that you understood the
>> mechanism of the conventional proofs at all. After this you proved
>> that you understood this mechanism far better that most everyone else.
>
> Two people can arrive at the same conclusion independently you know. I
> pointed out to you that [Strachey 1965] was pathological/erroneous due
> to the decider being part of or called by that which is being decided
> (P) which gives arise to a necessarily tri-state decision result with
> the third result state being that P is invalid.
>
> /Flibble
>

I said this back in 2004.

--
Copyright 2021 Pete Olcott

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

On 7/28/2021 11: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.
>

int Factorial(int n)
{ Output("Factorial(n)",n);
if (n > 1)
return n * Factorial(n - 1);
else
return 1;
}

Then Factorial(3) wold be rejected as invalid.

> This is a troll.
>
> /Flibble
>

--
Copyright 2021 Pete Olcott

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