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 -
Replying to @avibryant
@avibryant@manyangled isn't that append: https://github.com/twitter/algebird/blob/develop/algebird-core/src/main/scala/com/twitter/algebird/Aggregator.scala#L235 …2 replies 0 retweets 0 likes
@posco @manyangled oh. So it is :) We just don't have a lot of (any?) optimized append implementations.
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.