Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.theory > #37148 > unrolled thread

The contradiction that the HP is predicated on is detectable ..

Back to article view | Back to comp.theory

Contents

  The contradiction that the HP is predicated on is detectable .. Mr Flibble <flibble@reddwarf.jmc> - 2021-07-27 18:34 +0100
    Re: The contradiction that the HP is predicated on is detectable .. olcott <NoOne@NoWhere.com> - 2021-07-27 12:59 -0500
    Re: The contradiction that the HP is predicated on is detectable .. Peter <peterxpercival@hotmail.com> - 2021-07-27 20:02 +0100
      Re: The contradiction that the HP is predicated on is detectable .. olcott <NoOne@NoWhere.com> - 2021-07-27 14:14 -0500
        Re: The contradiction that the HP is predicated on is detectable .. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-27 12:23 -0700
          Re: The contradiction that the HP is predicated on is detectable .. olcott <NoOne@NoWhere.com> - 2021-07-27 14:36 -0500
        Re: The contradiction that the HP is predicated on is detectable .. Peter <peterxpercival@hotmail.com> - 2021-07-27 20:46 +0100
          Re: The contradiction that the HP is predicated on is detectable .. olcott <NoOne@NoWhere.com> - 2021-07-27 17:13 -0500
            Re: The contradiction that the HP is predicated on is detectable .. Richard Damon <Richard@Damon-Family.org> - 2021-07-27 15:56 -0700
              Re: The contradiction that the HP is predicated on is detectable .. olcott <NoOne@NoWhere.com> - 2021-07-27 18:06 -0500
                Re: The contradiction that the HP is predicated on is detectable .. Richard Damon <Richard@Damon-Family.org> - 2021-07-27 16:17 -0700
        Re: The contradiction that the HP is predicated on is detectable .. Mr Flibble <flibble@reddwarf.jmc> - 2021-07-27 20:47 +0100
          Re: The contradiction that the HP is predicated on is detectable .. olcott <NoOne@NoWhere.com> - 2021-07-27 16:06 -0500
            Re: The contradiction that the HP is predicated on is detectable .. Mr Flibble <flibble@reddwarf.jmc> - 2021-07-28 17:35 +0100
              Re: The contradiction that the HP is predicated on is detectable .. olcott <NoOne@NoWhere.com> - 2021-07-28 12:31 -0500
        Re: The contradiction that the HP is predicated on is detectable .. André G. Isaak <agisaak@gm.invalid> - 2021-07-27 13:58 -0600
          Re: The contradiction that the HP is predicated on is detectable .. olcott <NoOne@NoWhere.com> - 2021-07-27 17:13 -0500
        Re: The contradiction that the HP is predicated on is detectable .. Richard Damon <news.x.richarddamon@xoxy.net> - 2021-07-27 13:05 -0700
          Re: The contradiction that the HP is predicated on is detectable .. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-27 13:11 -0700
        Re: The contradiction that the HP is predicated on is detectable .. Jeff Barnett <jbb@notatt.com> - 2021-07-27 15:04 -0600
          Re: The contradiction that the HP is predicated on is detectable .. olcott <NoOne@NoWhere.com> - 2021-07-27 16:56 -0500
            Re: The contradiction that the HP is predicated on is detectable .. Jeff Barnett <jbb@notatt.com> - 2021-07-28 00:44 -0600
              Re: The contradiction that the HP is predicated on is detectable .. olcott <NoOne@NoWhere.com> - 2021-07-28 08:57 -0500
          Re: The contradiction that the HP is predicated on is detectable .. Mr Flibble <flibble@reddwarf.jmc> - 2021-07-28 17:36 +0100
            Re: The contradiction that the HP is predicated on is detectable .. olcott <NoOne@NoWhere.com> - 2021-07-28 12:33 -0500
            Re: The contradiction that the HP is predicated on is detectable .. Jeff Barnett <jbb@notatt.com> - 2021-07-28 11:40 -0600
              Re: The contradiction that the HP is predicated on is detectable .. olcott <NoOne@NoWhere.com> - 2021-07-28 12:53 -0500
                Re: The contradiction that the HP is predicated on is detectable .. Richard Damon <Richard@Damon-Family.org> - 2021-07-28 11:25 -0700

Page 1 of 2  [1] 2  Next page →

#37148 — The contradiction that the HP is predicated on is detectable ..

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

[toc] | [next] | [standalone]

#37149

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

[toc] | [prev] | [next] | [standalone]

#37155

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

[toc] | [prev] | [next] | [standalone]

#37157

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

[toc] | [prev] | [next] | [standalone]

#37158

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

[toc] | [prev] | [next] | [standalone]

#37159

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

[toc] | [prev] | [next] | [standalone]

#37161

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

[toc] | [prev] | [next] | [standalone]

#37171

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

[toc] | [prev] | [next] | [standalone]

#37174

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.

[toc] | [prev] | [next] | [standalone]

#37175

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

[toc] | [prev] | [next] | [standalone]

#37176

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.

[toc] | [prev] | [next] | [standalone]

#37162

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

[toc] | [prev] | [next] | [standalone]

#37168

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

[toc] | [prev] | [next] | [standalone]

#37195

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

[toc] | [prev] | [next] | [standalone]

#37200

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

[toc] | [prev] | [next] | [standalone]

#37164

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.

[toc] | [prev] | [next] | [standalone]

#37170

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

[toc] | [prev] | [next] | [standalone]

#37165

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

[toc] | [prev] | [next] | [standalone]

#37166

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.

;^)

[toc] | [prev] | [next] | [standalone]

#37167

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.theory

csiph-web