please follow up code modifications on SANDBOX-404 http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/
On Sat, Mar 3, 2012 at 5:11 PM, Claudio Squarcella <squar...@dia.uniroma3.it> wrote: > Hi Simone, > > answering briefly below: > > >> Vertex is something we can safety drop because we >> know its nature at priori, markers are unnecessary.This is fine. > > > +1. > > >> what is the sense, at that point, on keeping the Edge?!! It would be >> more than enough to know which is the Head and which is the Tail in >> the Edge to get the W! > > > good observation. My 2 cents: it might still make sense for users to map > their existing domain (including "edges") to the graph (e.g. Routers to > Vertices and Cables to Edges) and "get it back" as soon as they are done > with graph operations (e.g. once they find the shortest path, they > automatically have the sequence of Cables they need). > >> maybe because they implement OrderedMonoid? :) >> [...] >> >> how much would Addition and Multiplication interface differ each other? >> [...] >> that would be fine, what is not clear is that Monoids expose the same >> interface, so *Operations class implementation canot declare same >> method multiple times > > > answering all the above: that is another reason why I would like our current > Monoid to be called Addition (and Addition#sum instead of Monoid#append, > etc), so that it is semantically clearer and later we can introduce > Multiplication as a completely independent interface. > > >> enough talk IMHO, time to code and make concrete proposals > > > Sure! > I'll play with weights first, because I already know what I want to do. > As for Vertex/Edge markers I still see valuable feedback coming in, so I'll > wait a bit. > > Branching is ok -- especially for the second part which sounds like a real > earthquake ;) > > > Ciao, > Claudio > > -- > Claudio Squarcella > PhD student at Roma Tre University > http://www.dia.uniroma3.it/~squarcel > http://squarcella.com/ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
