A followup on these issues, after experimenting a bit with reducers, just for
anyone who may be interested:
- Naive use of reducers in place of seq functions, throughout my program, got
messy and led to some new problems with memory management, I think (or at least
to jerkier execution over
Oops -- something was wrong with my benchmarks, and my improvements on the
order of 1/3 was wrong. I still see improvements with r/fold as compared to my
agent-based approach, but the difference now appears to be only something like
1/20.
-Lee
On Jun 5, 2014, at 7:19 PM, Lee Spector
Fair enough. Fortunately, Clojure provides so many different tools to
select from in creating you perfect recipe. ;-)
I'm glad to hear that reducers ultimately provided you with some benefits
over your previous concurrency approach.
The one thing that seems rather odd to me though is that your
On Jun 5, 2014, at 8:51 PM, Gary Johnson gwjoh...@uvm.edu wrote:
Fair enough. Fortunately, Clojure provides so many different tools to select
from in creating you perfect recipe. ;-)
I'm glad to hear that reducers ultimately provided you with some benefits
over your previous concurrency
On Jun 2, 2014, at 7:14 PM, Gary Johnson gwjoh...@uvm.edu wrote:
Hey Lee,
I would second Jozef's suggestion that you look into using the reducers
library when you need non-lazy sequence operations. [etc]
On Jun 2, 2014, at 10:38 PM, Lee Spector lspec...@hampshire.edu wrote:
Gary:
Hey Lee,
(vec ...) is NOT the same as (into [] ...) in this case.
Whenever you use a reducing function, like r/map, r/filter, r/mapcat, and
so on, you are not, in fact, performing any computations on the collection
to which you apply it. These functions simply wrap the collection with a
On Jun 4, 2014, at 12:59 PM, Gary Johnson gwjoh...@uvm.edu wrote:
Hey Lee,
(vec ...) is NOT the same as (into [] ...) in this case.
[etc]
Thanks Gary -- very clear and helpful.
-Lee
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to
Hey Lee, answers below. Also make sure to read my other post at 12:59pm
today regarding the behavior of vec vs. into for reducible collections.
On Wednesday, June 4, 2014 12:51:45 PM UTC-4, Lee wrote:
Some quick notes and a question from my first look into this:
- I watched a Rich Hickey
Although your original complaint was about clojure seqs being lazy. It
should be noted that reducers are also lazy down to the point of a fold or
reduce, so I'm not sure what you're really getting there. It wouldn't be
hard at all to write map, filter, remove, etc. in terms of list operations.
On Jun 4, 2014, at 1:20 PM, Gary Johnson gwjoh...@uvm.edu wrote:
- If I operate on a vector with a sequence of r/map and r/filter operations
and finally with into [] to get back a vector, then I think that fold will
be called within the call to into, and that parallelism should happen
On Jun 4, 2014, at 1:29 PM, Timothy Baldridge tbaldri...@gmail.com wrote:
Although your original complaint was about clojure seqs being lazy. It should
be noted that reducers are also lazy down to the point of a fold or reduce,
so I'm not sure what you're really getting there. It wouldn't
On Mon 2 Jun 2014 at 10:38:23PM -0400, Lee Spector wrote:
PS would a call to vec do the same thing as into [] here?
IIRC vec and into [] are equivalent unless the source collection
implements IEditableCollection, in which case transients are used for a
significant performance boost.
guns
On Monday, June 2, 2014 3:32:59 PM UTC-5, Lee wrote:
I've generally liked Clojure's pervasive laziness. It's cute and it
sometimes permits lovely, elegant approaches to particular programming
problems.
After worrying about some bad potential problems with mutation of data
structures
mapv
a bit shorter :)
Luc P.
I've generally liked Clojure's pervasive laziness. It's cute and it sometimes
permits lovely, elegant approaches to particular programming problems. And
although I've long known that it can get you into trouble in a few unusual
cases -- I think I recall
Funny, I posted an article of my Clojure gotcha's today
(http://www.russet.org.uk/blog/2991), and this is one of them. I've also had
very nasty bugs, in addition to the general hassle of wrapping a Java API which
works through side-effects.
I created a few functions covering the most common
Reducers [1] provide eager variants of some core seq functions (map,
filter, etc.). Note that they do not cache the result, so they recompute it
every time you use their result.
[1] http://clojure.org/reducers
On Mon, Jun 2, 2014 at 10:32 PM, Lee Spector lspec...@hampshire.edu wrote:
I've
On Jun 2, 2014, at 4:51 PM, Softaddicts lprefonta...@softaddicts.ca wrote:
mapv
a bit shorter :)
Luc P.
Thanks Luc. I have indeed migrated to mapv for many cases and I could have for
the specific final fix for the example I posted. But there are lots of other
fixes that I made earlier
On Jun 2, 2014, at 4:52 PM, Phillip Lord phillip.l...@newcastle.ac.uk wrote:
Funny, I posted an article of my Clojure gotcha's today
(http://www.russet.org.uk/blog/2991), and this is one of them. I've also had
very nasty bugs, in addition to the general hassle of wrapping a Java API
which
On Jun 2, 2014, at 4:52 PM, Jozef Wagner jozef.wag...@gmail.com wrote:
Reducers [1] provide eager variants of some core seq functions (map, filter,
etc.). Note that they do not cache the result, so they recompute it every
time you use their result.
[1] http://clojure.org/reducers
Thanks
Hey Lee,
I would second Jozef's suggestion that you look into using the reducers
library when you need non-lazy sequence operations. Although a major
motivation of Rich's work was clearly to enable easy parallel folding via
fork/join, the fold function is only one of many in this library.
Gary: That's compelling indeed, and I will look into it more!
Thanks,
-Lee
PS would a call to vec do the same thing as into [] here?
On Jun 2, 2014, at 7:14 PM, Gary Johnson gwjoh...@uvm.edu wrote:
Hey Lee,
I would second Jozef's suggestion that you look into using the reducers
21 matches
Mail list logo
