On 2007-02-15, Gabriel Genellina <[EMAIL PROTECTED]> wrote:
>> I'm not sure what you mean. The above support is enough for
>> tail recursion, mutual recursion, and any other tail call to
>> be "optimized."
>
> I only want to say that tail *recursion* can be eliminated
> trivially transforming the
En Thu, 15 Feb 2007 16:35:25 -0300, Neil Cerutti <[EMAIL PROTECTED]>
escribió:
> On 2007-02-15, Gabriel Genellina <[EMAIL PROTECTED]> wrote:
>> En Thu, 15 Feb 2007 13:37:19 -0300, Neil Cerutti <[EMAIL PROTECTED]>
>> escribió:
>>
>>> On 2007-02-15, Gabriel Genellina <[EMAIL PROTECTED]> wrote:
>>>
On 2007-02-15, Gabriel Genellina <[EMAIL PROTECTED]> wrote:
> En Thu, 15 Feb 2007 13:37:19 -0300, Neil Cerutti <[EMAIL PROTECTED]>
> escribió:
>
>> On 2007-02-15, Gabriel Genellina <[EMAIL PROTECTED]> wrote:
>>> En Wed, 14 Feb 2007 10:41:53 -0300, Neil Cerutti <[EMAIL PROTECTED]>
>>> escribió:
>>
En Thu, 15 Feb 2007 13:37:19 -0300, Neil Cerutti <[EMAIL PROTECTED]>
escribió:
> On 2007-02-15, Gabriel Genellina <[EMAIL PROTECTED]> wrote:
>> En Wed, 14 Feb 2007 10:41:53 -0300, Neil Cerutti <[EMAIL PROTECTED]>
>> escribió:
>>> So the effect is that mutual recursion isn't actually any
>>> hard
On 2007-02-15, Gabriel Genellina <[EMAIL PROTECTED]> wrote:
> En Wed, 14 Feb 2007 10:41:53 -0300, Neil Cerutti <[EMAIL PROTECTED]>
> escribió:
>> So the effect is that mutual recursion isn't actually any
>> harder.
>
> But some kind of language support is required in this case. At
> least I don'
[EMAIL PROTECTED] wrote:
> Hi,
> I have a program which literately finds the object that overlapping a
> point. The horizontal and vertical search are called recursively from
> inside each other.
> ...
in case you ever need deeply nested recursion:
one solution is to use the already mentioned sy
En Wed, 14 Feb 2007 10:41:53 -0300, Neil Cerutti <[EMAIL PROTECTED]>
escribió:
> On 2007-02-14, Gabriel Genellina <[EMAIL PROTECTED]> wrote:
>> Python does not do "tail recursion optimization" (at
>> least, I'm not aware of that).
>
> To be just a little pedantic, it's "tail call optimization".
On 2007-02-14, Gabriel Genellina <[EMAIL PROTECTED]> wrote:
> En Wed, 14 Feb 2007 03:09:37 -0300, [EMAIL PROTECTED]
><[EMAIL PROTECTED]> escribió:
>> Is this way of implementation fill the stack space with the
>> local variables inside each call. If this is not good, is
>> there a better way t
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
I am OK with calls being stacked, but I wondering will the local
variables be stacked given that return statement is followed by the
function call?
def test():
x = 22
y = 33
z = x+y
return anotherFunction(z)
On Feb 14, 11:09 am, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> Hi,
> I have a program which literately finds the object that overlapping a
> point. The horizontal and vertical search are called recursively from
> inside each other.
> Is this way of implementation fill thestackspace with th
En Wed, 14 Feb 2007 04:23:46 -0300, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> escribió:
> I am OK with calls being stacked, but I wondering will the local
> variables be stacked given that return statement is followed by the
> function call?
>
> def test():
> x = 22
> y = 33
> z = x+y
> retu
On Feb 14, 11:45 am, "Gabriel Genellina" <[EMAIL PROTECTED]>
wrote:
> En Wed, 14 Feb 2007 03:09:37 -0300, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> escribió:
>
> > Hi,
> > I have a program which literately finds the object that overlapping a
> > point. The horizontal and vertical search are called r
En Wed, 14 Feb 2007 03:09:37 -0300, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> escribió:
> Hi,
> I have a program which literately finds the object that overlapping a
> point. The horizontal and vertical search are called recursively from
> inside each other.
> Is this way of implementation fill th
13 matches
Mail list logo
