Thanks Leif, thanks folks, these are good tips.
On Mon, Nov 18, 2013 at 4:12 AM, Leif wrote:
>
> Hi, Alexandru.
>
> If you just need more performance on vectors only, there are the core
> functions mapv, filterv, and subvec (O(1), which can be used to implement
> takev and dropv). Also, lookin
On Sat, Nov 16, 2013 at 9:00 PM, Cedric Greevey wrote:
> This efficiency is why built-in functions to map, filter, etc. vectors to
> vectors aren't provided
>
Well, there is mapv and filterv.
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To
Hi, Alexandru.
If you just need more performance on vectors only, there are the core
functions mapv, filterv, and subvec (O(1), which can be used to implement
takev and dropv). Also, looking at the source of mapv and filterv is
instructive, because they use transients internally; you might do
This efficiency is why built-in functions to map, filter, etc. vectors to
vectors aren't provided; better to use (into []) on a chain of
seq-outputting transformations of a vector than to chain these hypothetical
vector-native functions.
OTOH, it occurs to me that efficient chaining can still be a
I don't know if it is idiomatic, but it certainly looks like a good way to
achieve the desired effect.
If you chained together calls to several functions like your example
only-evens, it would not be lazy, and it would build up a separate instance
of collections of the original type at each step o
Hi,
I'm trying to understand the design of Clojure's collections and one
thing that I find odd is the return of functions operating on sequences.
Like for instance a call such as this will return a lazy-seq and not a
vector:
(drop 2 [1 2 3 4])
The reason why I find it odd is that data-struct
