Hi all guys, thanks a lot for the very hight valuable feedbacks, impressive, without any doubt.
IMHO Matthew's stuff should be absolutely part of a commons component, if they don't find a home in [graph] at 100%, they should be included in [math]!!! Discrete math has always been one of my preferred math classes and having Matthew contributing on that topic is something I have to take advantage to increase my knowledge :P I personally need to digest all that proposals to elaborate mine as well and share with you. Thanks all again! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Dec 15, 2011 at 1:37 PM, Matthew Pocock <turingatemyhams...@gmail.com> wrote: > Hi, > > On 15 December 2011 11:35, James Carman <ja...@carmanconsulting.com> wrote: > > >> public interface BinaryOperation<T> >> { >> public T execute(T operand1, T operand2); >> } >> >> Perhaps we can come up with an interface that combines the two >> aspects. I'm trying to think of mathematically what that would be >> called. By the way, what do you need to know "HasZero"? A sum >> operation has to have a "zero", doesn't it? > > > The mathematical hierarchy goes: semigroup -> monoid. > > http://en.wikipedia.org/wiki/Semigroup > http://en.wikipedia.org/wiki/Monoid > > You don't need a full group here as you are only interested in a single > operation, not a pair of interacting operations. There are several > JVM-hosted libraries that model this hierarchy to a greater or lesser > degree. scalaz uses: > > trait Semigroup[S] { > def append(s1: S > <http://scalaz.googlecode.com/svn/continuous/latest/browse.sxr/scalaz/Semigroup.scala.html#22357>, > s2: => S): S > <http://scalaz.googlecode.com/svn/continuous/latest/browse.sxr/scalaz/Semigroup.scala.html#22357> > } > > trait Zero[Z] { > val zero: Z > <http://scalaz.googlecode.com/svn/continuous/latest/browse.sxr/scalaz/Zero.scala.html#22160> > } > > trait Monoid[M] extends Zero > <http://scalaz.googlecode.com/svn/continuous/latest/browse.sxr/scalaz/Zero.scala.html#17945>[M] > with Semigroup > <http://scalaz.googlecode.com/svn/continuous/latest/browse.sxr/scalaz/Semigroup.scala.html#15476>[M] > > http://scalaz.googlecode.com/svn/continuous/latest/browse.sxr/scalaz/Semigroup.scala.html > http://scalaz.googlecode.com/svn/continuous/latest/browse.sxr/scalaz/Zero.scala.html > http://scalaz.googlecode.com/svn/continuous/latest/browse.sxr/scalaz/Monoid.scala.html > > If you're not used to reading scala, here's the essentially equivalent > definitions in Java: > > public interface Semigroup<S> { > public S append(S s1, S s2); > } > > public interface Zero<Z> { > > public Z zero(); > } > > public interface Monoid<M> extends > Zero<http://scalaz.googlecode.com/svn/continuous/latest/browse.sxr/scalaz/Zero.scala.html#17945><M>, > Semigroup<http://scalaz.googlecode.com/svn/continuous/latest/browse.sxr/scalaz/Semigroup.scala.html#15476> > <M> > > > So, given that you have Ordering<O> already (or is that Comparator<C>?), > I'd say that Weight is defined as: > > // insert comments here about the consistency of append and compare > public interface Weight<W> extends Monoid<W>, Ordered<W> > > Of course, a sensible default implementation of Weight would delegate to > Monoid and Ordered instances and you can then pray to the gods of hotspot > to inline this all away. > > public <W> Weight<W> weight(Monoid<W> m, Ordered<W> o) { > new Weight<W>() { > public W zero() { return m.zero(); } > ... > } > } > > Matthew > > -- > Dr Matthew Pocock > Integrative Bioinformatics Group, School of Computing Science, Newcastle > University > mailto: turingatemyhams...@gmail.com > gchat: turingatemyhams...@gmail.com > msn: matthew_poc...@yahoo.co.uk > irc.freenode.net: drdozer > skype: matthew.pocock > tel: (0191) 2566550 > mob: +447535664143 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
