Thanks so much Alan. Very clear.
Mimmo
On Tuesday, July 24, 2012 8:19:00 AM UTC+2, Alan Malloy wrote:
>
> I don't see how the definition of primitive-recursive is relevant to this.
> You can transform primitive recursion to tail recursion if you allocate a
> "stack" of your own on the heap, and
On Mon, Jul 23, 2012 at 3:14 PM, Mimmo Cosenza wrote:
> hi Merek and thanks for the link. But it does not answer my question.
> I was looking for a demonstration of the reducibility of (not tail)
> recursion to tail recursion. Or there is a demonstration of that, or nobody
> could say that a (not
I don't see how the definition of primitive-recursive is relevant to this.
You can transform primitive recursion to tail recursion if you allocate a
"stack" of your own on the heap, and don't mind that it might grow without
bound. Or you can transform to continuation-passing or trampolines
(fun
No, not any recursion can be expressed as a tail recursion. One example:
the Ackermann function (http://en.wikipedia.org/wiki/Ackermann_function)
On Saturday, July 21, 2012 11:15:33 AM UTC+2, Mimmo Cosenza wrote:
>
> Hi,
> a very basic question. Any "not tail recursion" code can be reduced to
>
Yes.
For example, you can have a look at CPS transformation.
If you want tail recursion and not tail calls, you can add
trampolining to the mix.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroup
hi Merek and thanks for the link. But it does not answer my question.
I was looking for a demonstration of the reducibility of (not tail)
recursion to tail recursion. Or there is a demonstration of that, or nobody
could say that a (not tail) recursion definition is always reducible to a
tail re
Discussion about this is in the penultimate paragraph
of http://c2.com/cgi/wiki?TailCallOptimization
and btw, there's difference between:
- tail recursion - function calls itself
- tail call - function calls whatever
Marek.
On Saturday, July 21, 2012 11:15:33 AM UTC+2, Mimmo Cosenza wrote:
>
On Mon, Jan 5, 2009 at 11:37 AM, Christophe Grand wrote:
> Stuart,
>
> Do you think rec-cat, rec-cons and reductions belong to seq-utils?
>
> Christophe
>
Find by me. I won't claim ownership over seq-utils or str-utils. As
far as I'm concerned, any contrib committers can add to them.
-Stuart
Chouser a écrit :
> On Mon, Jan 5, 2009 at 9:53 AM, Christophe Grand
> wrote:
>
>> Chouser a écrit :
>>
>>> This isn't in clojure.core yet (any reason why not?) so would you mind
>>> if I add it to clojure.contrib.seq-utils? Or of course you can do it
>>> if you prefer. :-)
>> hat do y
Chouser a écrit :
>> What do you think of adding rec-cons, rec-cat and your (fixed) cute
>> version instead to seq-utils?
>> (see http://clj-me.blogspot.com/2009/01/recursive-seqs.html for rec-cat
>> and rec-cons)
>>
>
> That'd be fine too, especially for rec-cons and rec-cat. The
> 'reducti
On Mon, Jan 5, 2009 at 9:53 AM, Christophe Grand wrote:
>
> Chouser a écrit :
>> On Dec 12 2008, 3:35 pm, Christophe Grand
>> wrote:
>>
>>> I was sure it was a job for iterate:
>>>
>>> (defn reductions
>>> "Returns a lazy seq of the intermediate values of the reduction (as
>>> per reduce) of
Chouser a écrit :
> On Dec 12 2008, 3:35 pm, Christophe Grand
> wrote:
>
>> I was sure it was a job for iterate:
>>
>> (defn reductions
>> "Returns a lazy seq of the intermediate values of the reduction (as
>> per reduce) of coll by f, starting with init."
>> ([f coll]
>>(if (seq col
On Dec 12 2008, 3:35 pm, Christophe Grand
wrote:
> I was sure it was a job for iterate:
>
> (defn reductions
> "Returns a lazy seq of the intermediate values of the reduction (as
> per reduce) of coll by f, starting with init."
> ([f coll]
> (if (seq coll)
> (for [s (iterate (fn [[x
On Dec 12, 3:35 pm, Christophe Grand wrote:
> I was sure it was a job for iterate:
>
> (defn reductions
> "Returns a lazy seq of the intermediate values of the reduction (as
> per reduce) of coll by f, starting with init."
> ([f coll]
>(if (seq coll)
> (for [s (iterate (fn [[x &
I was sure it was a job for iterate:
(defn reductions
"Returns a lazy seq of the intermediate values of the reduction (as
per reduce) of coll by f, starting with init."
([f coll]
(if (seq coll)
(for [s (iterate (fn [[x & s]] (if s
(lazy-cons (f
On Dec 7, 4:10 pm, Christophe Grand <[EMAIL PROTECTED]> wrote:
> Rich Hickey a écrit :> I think the problem is that in the original and
> subsequent versions,
> > work was being done in the current case that needn't be (checking the
> > status of coll), and that we need more laziness than lazy-
Rich Hickey a écrit :
> I think the problem is that in the original and subsequent versions,
> work was being done in the current case that needn't be (checking the
> status of coll), and that we need more laziness than lazy-cons gives
> us (we need to delay evaluation of one argument to the recur
On Dec 7, 5:29 am, Christophe Grand <[EMAIL PROTECTED]> wrote:
> Chouser a écrit :> Testing just now on large collections, the version using
> 'map' is
> > indeed not only slower, but also overflows the stack. Hm... and
> > perhaps I see why now. Is it computing the entire chain up to each
>
Chouser a écrit :
> Testing just now on large collections, the version using 'map' is
> indeed not only slower, but also overflows the stack. Hm... and
> perhaps I see why now. Is it computing the entire chain up to each
> result -- O(n^2), demanding n stack frames for the nth result?
>
The p
On Sat, Dec 6, 2008 at 4:27 AM, Christophe Grand <[EMAIL PROTECTED]> wrote:
>
> But I don't think it's still O(n). I searched for a way to define
> recursively such lists but the only way I found involves using mutation.
> Now with an atom it must be cleaner.
Your comprehension of such things is
Chouser a écrit :
> How about this one? Same results as in my previous post. Still as
> lazy as possible. Plus it's so cute!
>
> (defn reduction
> "Returns a lazy seq of the intermediate values of the reduction (as
> per reduce) of coll by f, starting with init."
> ([f coll]
>(if (seq
How about this one? Same results as in my previous post. Still as
lazy as possible. Plus it's so cute!
(defn reduction
"Returns a lazy seq of the intermediate values of the reduction (as
per reduce) of coll by f, starting with init."
([f coll]
(if (seq coll)
(lazy-cons (first coll
On Fri, Dec 5, 2008 at 9:55 PM, Chouser <[EMAIL PROTECTED]> wrote:
> Third time's charm?
Apparently not. Previous versions had a couple problems.
One was that when when no init was provided, the first element of the
collection was not emitted by itself. This is inconsistent with
Haskell's scan
Third time's charm? The previous versions of 'reduction' returned nil
for empty collection when no init was given. This version follows
'reduce' more closely, calling the given function with no arguments:
user=> (reduction + [])
(0)
--Chouser
--~--~-~--~~~---~--~---
On Fri, Dec 5, 2008 at 10:50 AM, Chouser <[EMAIL PROTECTED]> wrote:
> Google groups files section is having issues.
> Here's 'reduction' as discussed in IRC, mostly written by Rich.
I messed it up anyway -- tried to use if-let too early.
Try this patch instead.
--Chouser
--~--~-~--~~
On Friday 05 December 2008 08:00, Rich Hickey wrote:
> On Dec 5, 10:50 am, Chouser <[EMAIL PROTECTED]> wrote:
> > Google groups files section is having issues.
> > Here's 'reduction' as discussed in IRC, mostly written by Rich.
>
> Attachments are preferred - thanks!
It came through as an attachm
On Dec 5, 10:50 am, Chouser <[EMAIL PROTECTED]> wrote:
> Google groups files section is having issues.
> Here's 'reduction' as discussed in IRC, mostly written by Rich.
>
Attachments are preferred - thanks!
Rich
--~--~-~--~~~---~--~~
You received this message b
27 matches
Mail list logo
