In the olden lisp days, reduce was often preferred to
apply because apply could hit limits on the number of
arguments that could be passed to a function. Is that a
potential issue with clojure?
No. Clojure's `apply` is lazy. Varargs are passed to the
function as a lazy sequence, and it's up
str is much faster with apply than with reduce; in fact, with reduce
it is O(n^2), whereas with apply it is O(n). (The constants are better
with apply too.)
In general, (apply foo ...) takes advantage of any optimizations the
author of foo might be aware of for speeding up its operation when
I would say that with good reducers, the reduce approach can eliminate seq
creation and thus be at least a bit faster and less demanding for GC.
On Thu, Feb 13, 2014 at 4:16 PM, Michał Marczyk michal.marc...@gmail.comwrote:
str is much faster with apply than with reduce; in fact, with reduce
On Feb 13, 2014, at 08:56 , Stuart Sierra the.stuart.sie...@gmail.com wrote:
No. Clojure's `apply` is lazy. Varargs are passed to the
function as a lazy sequence, and it's up to the function to
realize them or not.
It's worth noting (for people who might try to rely on that laziness) that
On Feb 13, 2014, at 14:31 , Michael Gardner gardne...@gmail.com wrote:
On Feb 13, 2014, at 08:56 , Stuart Sierra the.stuart.sie...@gmail.com wrote:
No. Clojure's `apply` is lazy. Varargs are passed to the
function as a lazy sequence, and it's up to the function to
realize them or not.
My guess is that when using a rest-param a call to next is involved thus
realizing two elements of the sequence. A call to rest only realizes the
first element:
user (defn f [x] (println x) x)
#'user/f
user (defn s [n] (lazy-seq (cons (f n) (s (inc n)
#'user/s
user (def t (rest (s 0)))
0
On Feb 13, 2014, at 15:17 , Mauricio Aldazosa
mauricio.aldaz...@ciencias.unam.mx wrote:
My guess is that when using a rest-param a call to next is involved thus
realizing two elements of the sequence.
A destructured vararg is nil when there are no more items, which indeed
requires realizing
On Friday, February 7, 2014 2:23:33 AM UTC, Sean Corfield wrote:
On Feb 6, 2014, at 12:58 PM, Stuart Sierra
the.stua...@gmail.comjavascript:
wrote:
I think (reduce + (range N)) is commonly used in **examples**, not
necessarily in real applications.
I'd have to agree: I don't see
On Wednesday, February 12, 2014 8:46:41 AM UTC-5, Vincent wrote:
On a slightly different topic: why reduce and not apply?
The implementation of `+` with more than 2 arguments uses `reduce`
internally. So they amount to the same thing.
There isn't really a performance difference:
user=
On Wednesday, February 12, 2014 2:47:07 PM UTC, Stuart Sierra wrote:
On Wednesday, February 12, 2014 8:46:41 AM UTC-5, Vincent wrote:
On a slightly different topic: why reduce and not apply?
The implementation of `+` with more than 2 arguments uses `reduce`
internally. So they amount to
In the olden lisp days, reduce was often preferred to apply because apply
could hit limits on the number of arguments that could be passed to a
function. Is that a potential issue with clojure?
Thanks,
John
On Wed, Feb 12, 2014 at 12:06 PM, Vincent vhenneb...@gmail.com wrote:
On Wednesday,
On Feb 12, 2014, at 5:46 AM, Vincent vhenneb...@gmail.com wrote:
On Friday, February 7, 2014 2:23:33 AM UTC, Sean Corfield wrote:
On Feb 6, 2014, at 12:58 PM, Stuart Sierra the.stua...@gmail.com wrote:
I think (reduce + (range N)) is commonly used in *examples*, not necessarily
in real
On Wednesday, February 12, 2014 2:33:34 PM UTC-6, John Wiseman wrote:
In the olden lisp days, reduce was often preferred to apply because apply
could hit limits on the number of arguments that could be passed to a
function.
Still an issue with some Common Lisps. I've hit the limit in
On Wednesday, February 12, 2014 5:14:42 PM UTC-6, Mars0i wrote:
On Wednesday, February 12, 2014 2:33:34 PM UTC-6, John Wiseman wrote:
Is that a potential issue with clojure?
(range 1)
Then copy its output from the terminal window.
(apply + 'paste here )
CompilerException
Just to be clear, and to check my understanding, that's not an issue with
the number of arguments, right? It's a limit on the size of a literal or
something?
I ask because (apply + (range 1)) works fine, but maybe I've missed
some subtlety.
Thanks,
John
On Wed, Feb 12, 2014 at 3:32 PM,
Good question. I don't know. Maybe it's in the read stage, rather than in
evaluating arguments for + ?
On Wednesday, February 12, 2014 5:43:18 PM UTC-6, John Wiseman wrote:
Just to be clear, and to check my understanding, that's not an issue with
the number of arguments, right? It's a
Hi all,
I often see this code for summing up a range from 0-N : `(reduce +
(range N))`
However there is a much faster way for this : `(/ (* N (dec N)) 2)`
Do you think this should be in the language so that people do not use
the slow version?
Jim
--
You received this message because
This seems way too specialised to be in Clojure core.
- James
On 6 February 2014 10:59, Jim - FooBar(); jimpil1...@gmail.com wrote:
Hi all,
I often see this code for summing up a range from 0-N : `(reduce + (range
N))`
However there is a much faster way for this : `(/ (* N (dec N)) 2)`
Agreed, but this could be a nice rule for
https://github.com/jonase/kibit, maybe?
On 6 February 2014 12:42, James Reeves ja...@booleanknot.com wrote:
This seems way too specialised to be in Clojure core.
- James
On 6 February 2014 10:59, Jim - FooBar(); jimpil1...@gmail.com wrote:
Hi all,
I think (reduce + (range N)) is commonly used in **examples**, not
necessarily in real applications.
-S
On Thursday, February 6, 2014 5:59:43 AM UTC-5, Jim foo.bar wrote:
Hi all,
I often see this code for summing up a range from 0-N : `(reduce +
(range N))`
However there is a much
On Feb 6, 2014, at 12:58 PM, Stuart Sierra the.stuart.sie...@gmail.com wrote:
I think (reduce + (range N)) is commonly used in *examples*, not necessarily
in real applications.
I'd have to agree: I don't see anything like that in our 20kloc at World
Singles. I see a handful of (reduce + data)
21 matches
Mail list logo
