The 'prepare' operation considered harmful in #Algebird aggregation
http://erikerlandson.github.io/blog/2015/11/24/the-prepare-operation-considered-harmful-in-algebird/ …
-
-
Replying to @manyangled
@manyangled yep, agreed, we should extend Aggregator to include update with the default implementation you show.2 replies 0 retweets 0 likes -
Replying to @avibryant
@avibryant what if: case class MonoidUpdate(mon: Monoid, upd: (m, e) => m) extends Monoid and then do: mon match { ... } to detect subclass1 reply 0 retweets 0 likes -
Replying to @manyangled
@manyangled it feels wrong to me to extend Monoid to know about a whole new type. Aggregator already knows about e:A, better there.1 reply 0 retweets 0 likes -
Replying to @avibryant
@avibryant I can see the drawbacks. At the end of the day my priority is mostly taking advantage of the faster formulation, in some way1 reply 0 retweets 0 likes -
Replying to @manyangled
@manyangled well, I'm happy to merge a PR that just adds update(b: B, a: A) to the Aggregator trait with a default implementation.3 replies 0 retweets 0 likes
@manyangled I don't think we need the monoid constraint in that interface; you might need it for certain usage patterns.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.