On Jun 5, 2014, at 8:51 PM, Gary Johnson 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 approach.
>
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 g
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 wrote
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 ti
On Jun 4, 2014, at 1:29 PM, Timothy Baldridge 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 be hard at all
> t
On Jun 4, 2014, at 1:20 PM, Gary Johnson 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
> there... right
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.
Perh
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
On Jun 4, 2014, at 12:59 PM, Gary Johnson 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 this group,
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
ki
> On Jun 2, 2014, at 7:14 PM, Gary Johnson 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 wrote:
>
> Gary: That's compelling indeed, and
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
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.
gun
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 wrote:
> Hey Lee,
>
> I would second Jozef's suggestion that you look into using the reducers
> library when y
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. Thi
On Jun 2, 2014, at 4:52 PM, Jozef Wagner 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 Josef. I haven't
On Jun 2, 2014, at 4:52 PM, Phillip Lord 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 works through side-effec
On Jun 2, 2014, at 4:51 PM, Softaddicts 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 in the same project,
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 wrote:
>
> I've generally liked Clojure
e 2014 21:32
To: clojure@googlegroups.com
Subject: non-lazy clojure?
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
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
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 seeing a nice blog post on issues related
22 matches
Mail list logo
