Re: Reducers exception when calling into

Thanks very much for the quick response. From your hints, I tried switching uses of into to r/foldcat and it worked. On Thursday, May 11, 2017 at 4:44:37 PM UTC-6, Alex Miller wrote: > > The symptoms sound like you are running into a case where there are > multiple protocol branches that apply

Re: reducers and sets/PersistentSet

Get cracking! :) On Tuesday, November 10, 2015 at 10:44:33 AM UTC-6, retnuH wrote: > > That's what I was thinking... > > I may try to put together a patch. > > But it may have to wait until after Clojure/Conj! Still don't have > presentation finished... > > H > > On Tuesday, 10 November 2015 16:

Re: reducers and sets/PersistentSet

That's what I was thinking... I may try to put together a patch. But it may have to wait until after Clojure/Conj! Still don't have presentation finished... H On Tuesday, 10 November 2015 16:26:58 UTC, Alex Miller wrote: > > Persistent sets are really persistent maps under the hood, so in pri

Re: reducers and sets/PersistentSet

Persistent sets are really persistent maps under the hood, so in principle doesn't seem like there's any reason that shouldn't work. On Tuesday, November 10, 2015 at 10:23:19 AM UTC-6, retnuH wrote: > > Hi there, I was playing with reducers recently, and was wondering why > PersistentSets aren't

Re: reducers question

On Wed, Jul 15, 2015 at 12:02 PM, Daniel Higginbotham < nonrecurs...@gmail.com> wrote: > Surely reducers/map should be faster, but it doesn’t seem like I’ve done > something wrong? This is driving me crazy :) It is much faster, and runs in parallel, if you use fold. Try this; (defn fold-into-v

Re: reducers question

Sweet, thanks everyone for your responses! This was very helpful! r/foldcat did the trick. It looks like it's faster than pmap by about 10%. Also, I'm happy to have my sanity back. Thank you! Daniel On Wednesday, July 15, 2015 at 12:38:39 AM UTC-4, James Reeves wrote: > > Reducers and pmap hav

Re: reducers question

You might want to check out this talk by Leon Barrett at Clojure/West 2015 https://www.youtube.com/watch?v=BzKjIk0vgzE&index=2&list=PLZdCLR02grLrKAOj8FJ1GGmNM5l7Okz0a Erik. > On 15. jul. 2015, at 05.02, Daniel Higginbotham > wrote: > > I’ve been trying to better understand ways to increase th

Re: reducers question

Reducers and pmap have different approaches to concurrency. pmap works a lot like map, except that instead of evaluating the seq one item at a time, it spins up N threads which work on the next N items in parallel. N is 2 + the number of CPU cores you have. The reducers library works in a rather

Re: Reducers question

Cat is just missing a print-method entry. Try (into [] (r/fold 1 r/cat r/append! [1 2 3])), the result is what you'd expect. The n parameter isn't actually about parallelism but partition size. Fork/Join will decide the parallelism. In the case of n=1 the input will be split into 3 partition of

Re: Reducers newbie question

Indeed, that was my really bad example with 100. On Saturday, April 27, 2013 4:19:07 PM UTC+3, Alan Busby wrote: > > > On Sat, Apr 27, 2013 at 10:01 PM, Stanislav Yurin > > > wrote: > >> By the way, fold function has [n combinef reducef coll] implementation, >> where n is number of elements col

Re: Reducers newbie question

On Sat, Apr 27, 2013 at 10:01 PM, Stanislav Yurin wrote: > By the way, fold function has [n combinef reducef coll] implementation, > where n is number of elements collection is folded by. 512 is just the > default. > Yep I misspoke there, but it is still one of the tricks to be aware of. Lots o

Re: Reducers newbie question

Thanks Alan, looking into it. By the way, fold function has [n combinef reducef coll] implementation, where n is number of elements collection is folded by. 512 is just the default. On Saturday, April 27, 2013 3:51:39 PM UTC+3, Alan Busby wrote: > > On Sat, Apr 27, 2013 at 7:35 PM, Stanislav Yur

Re: Reducers newbie question

On Sat, Apr 27, 2013 at 7:35 PM, Stanislav Yurin wrote: > Actually, what I was trying to do, is to prototype multithreaded i/o > operation via reducers. And then use fold to regulate number of concurrent > operations. > But now something tells me I am doing not very clever thing. > I'm not entir

Re: Reducers newbie question

Yep, thanks, my bad. I got the point. Actually, what I was trying to do, is to prototype multithreaded i/o operation via reducers. And then use fold to regulate number of concurrent operations. But now something tells me I am doing not very clever thing. On Friday, April 26, 2013 5:27:46 PM UTC

Re: Reducers newbie question

+1 ! I use 'fold-into-vec' regularly :) Jim On 26/04/13 18:07, Alan Busby wrote: Some additional pointers here (this is a little old though); http://www.thebusby.com/2012/07/tips-tricks-with-clojure-reducers.html On Fri, Apr 26, 2013 at 11:51 PM, László Török >

Re: Reducers newbie question

Some additional pointers here (this is a little old though); http://www.thebusby.com/2012/07/tips-tricks-with-clojure-reducers.html On Fri, Apr 26, 2013 at 11:51 PM, László Török wrote: > Hi, > > Not sure what you are trying to do, but xxx is a lazy seq, thus it can > only be consumed sequentia

Re: Reducers newbie question

Hi, Not sure what you are trying to do, but xxx is a lazy seq, thus it can only be consumed sequentially and fold falls back to reduce You need a vector. Las Sent from my phone On Apr 26, 2013 4:46 PM, "Stanislav Yurin" wrote: > I was assuming that following code will fold in parallel, but it

Re: Reducers reduce my performance

Kevin Downey writes: Hi Kevin, >> This is the new version using reducers (:as r). The problem here is >> that to stop the iteration, one has to reduce the intermediate result >> in every step and check if new reachable vertices (n) could be found. >> If so, we need to do another iteration. > >

Re: Reducers reduce my performance

On Fri, Sep 14, 2012 at 4:22 AM, Tassilo Horn wrote: > Hi all, > > I have some code which uses a lot of map/mapcat/filter stuff and is > totally eager (result is always an ordered set). That looked to me like > a good candidate for reducers. > > Basically, my code enables me to write something li

Re: Reducers

On Wed, Jun 27, 2012 at 4:57 PM, Leif wrote: > Min, like intersection, has a noncomputable "identity" value -- infinity. > And max and min are used in many more algorithms than intersection, so maybe > this will start some discussion. It seems to me the reducers framework is clearly documented to

Re: Reducers

Christian: Thank you for asking for additional reading material. Nicolas: Thank you for providing additional reading material. On Thursday, May 10, 2012 at 7:02 AM, nicolas.o...@gmail.com wrote: > I can describe the background to understand my last email. > > From the programming point of view,

Re: Reducers

OK, the complete silence leads me to believe that not many people reduce with set/intersection. However, I thought of a couple of other functions that don't work with the new framework: max and min. user> (require '[clojure.core.reducers :as r]) user=> (reduce min [1 2]) 1 user=> (r/reduce min

Re: Reducers

>From the article: "The combining fn must supply an identity value when called with no arguments" This means that you can't use combining functions whose identity value can't be computed, but satisfies the proper rules. E.g. set intersection: (intersection) == e == the set of all possible ele

Re: Reducers

Fixed - thanks. Rich On May 15, 2012, at 3:54 PM, Robert McIntyre wrote: > There's a right parenthesis missing at > http://clojure.com/blog/2012/05/15/anatomy-of-reducer.html : > > Now: > > (reduce + 0 (map inc [1 2 3 4])) > ;;becomes > (reduce + 0 (reducer [1 2 3 4] (mapping inc)) < MISSING P

Re: Reducers

There's a right parenthesis missing at http://clojure.com/blog/2012/05/15/anatomy-of-reducer.html : Now: (reduce + 0 (map inc [1 2 3 4])) ;;becomes (reduce + 0 (reducer [1 2 3 4] (mapping inc)) < MISSING PAREN under the heading "Reducers" sincerely, --Robert McIntyre, Dylan Holmes On Tue, Ma

Re: Reducers

I've written another post which goes into the reducers in more detail: http://clojure.com/blog/2012/05/15/anatomy-of-reducer.html Rich On May 10, 2012, at 1:26 PM, Christian Romney wrote: > > > On Thursday, May 10, 2012 8:02:09 AM UTC-4, Nicolas Oury wrote: > I can describe the background to

Re: Reducers

It's fixed now. On Friday, May 11, 2012 12:30:47 PM UTC-4, Sean Corfield wrote: > > Just to clarify: Clojure isn't building at the moment _on > build.clojure.org_ but you can build it yourself easily enough: > > -- You received this message because you are subscribed to the Google Groups "Cloj

Re: Reducers

On Fri, May 11, 2012 at 9:17 AM, Sean Corfield wrote: > Reducers are part of the 1.5.0 master branch. The only reason they're > not already available in a master-SNAPSHOT build is because Clojure > isn't building at the moment due to the jsr166y change and Java 6 > dependency. Just to clarify: Cl

Re: Reducers

On Fri, May 11, 2012 at 6:28 AM, Softaddicts wrote: > I may be a bit aggressive here :) but will this be ready for 1.5 ? Or > available > as an independent feature ? (I am not sure about this given the name) Reducers are part of the 1.5.0 master branch. The only reason they're not already availa

Re: Reducers

Hi Rich, I may be a bit aggressive here :) but will this be ready for 1.5 ? Or available as an independent feature ? (I am not sure about this given the name) I intend to skip 1.4 depending on our delivery cycles and the availability of 1.5, we are about to move 1.3 in prod here and my eyes are

Re: Reducers

On Fri, May 11, 2012 at 12:47 AM, Rich Hickey wrote: > IMO, Nicolas' material is a distraction in understanding reducers, except as > historical background. I perfectly agree. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, s

Re: Reducers

IMO, Nicolas' material is a distraction in understanding reducers, except as historical background. The reducers library is a rejection/avoidance of the primacy of recursively/generatively defined data structures and the operations thereon. I recommend, rather than reading about stream fusion,

Re: Reducers

On Thursday, May 10, 2012 8:02:09 AM UTC-4, Nicolas Oury wrote: > > I can describe the background to understand my last email. Thank you very much for taking the time to post all of that–I've got some reading to do for sure. -- You received this message because you are subscribed to the Go

Re: Reducers

I'm with you Christian, maybe a code example would be very helpful. Thank you guys, Nico 2012/5/10 Christian Romney > I would be indebted to you if you could point me in the direction of the > reading material necessary to follow this discussion. I'm afraid I'm > currently out of my depth, but

Re: Reducers

I can describe the background to understand my last email. >From the programming point of view, I have been told since yesterday that what I explained has already been explained better in "Stream Fusion From Lists to Streams to Nothing at All" from Coutts Leschinskiy and Stewart: metagraph.org/pa

Re: Reducers

I would be indebted to you if you could point me in the direction of the reading material necessary to follow this discussion. I'm afraid I'm currently out of my depth, but very eager to understand. Sincerely, Christian Romney -- You received this message because you are subscribed to the Goo

Re: Reducers

On Wed, May 9, 2012 at 1:00 PM, Rich Hickey wrote: > This analogy is not quite right. > >> (fn [n] (vector n (+ n 1)) > > is not a reducing fn. Tt is a cons cell builder, and the Church encoding > builds lists. > It is because I did not write it in the right way. Sorry about that. It can be made

Re: Reducers

This analogy is not quite right. > (fn [n] (vector n (+ n 1)) is not a reducing fn. Tt is a cons cell builder, and the Church encoding builds lists. The point of this library is to define map/filter etc *without* using lists/streams - not as input, not as output, not producing links/thunks etc

Re: Reducers

It looks very good. Just a few side-notes: - this representation is quite well known, as it is the Church encoding of list, often used in System F, for example. It corresponds to stating the definition of sequences as the initial algebra of F A = 1 + Any x A. - you can play a dual trick for S

Re: Reducers

On Wed, May 9, 2012 at 4:26 PM, Christian Romney wrote: > Am I mistaken or is fork/join Java 7? Anyone have this running on OS X yet? > If so with the Oracle preview or Open JDK? Yes, it's a part of Java 7, but there is also a reference implementation of the spec (jsr166y) available as a standal

Re: Reducers

Yet another example of doing more, by complecting less, a mantra I'm continuing to pursue. Awesome library, can't wait to use it and see the performance benefits. On Tuesday, May 8, 2012 11:20:37 AM UTC-4, Rich Hickey wrote: > > I'm happy to have pushed [1] today the beginnings of a new Clojure

Re: Reducers

On Tue May 8 17:14 2012, kovas boguta wrote: > Will definitely be using this, thanks! One question: > > "Those IFn.LLL, DDD etc primitive-taking function interfaces can now > spring to life." > > Can someone unpack this? What are those things, why does this allow > them to exist, why do we need

Re: Reducers

Will definitely be using this, thanks! One question: "Those IFn.LLL, DDD etc primitive-taking function interfaces can now spring to life." Can someone unpack this? What are those things, why does this allow them to exist, why do we need them, what can be built with them? On Tue, May 8, 2012 at

Re: Reducers

My understanding is that reducers/map merely returns a new function (or something like a function, maybe an instance of IReducible or something), and all actual computation is done during the reduce. So dynamic bindings around the scope of the map have no effect at all. On May 8, 10:57 am, Mark En

Re: Reducers

Exciting! I'm having trouble visualizing at what points the computation is actually executed, and therefore, I'm not clear on how this feature interacts with dynamic binding. If the reducers/map occurs in one dynamic binding context, and the fold occurs in another, what happens? -- You received