lol, I'll take a look at it as soon as possible!!! thanks!
-Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Feb 20, 2012 at 7:27 PM, Claudio Squarcella <squar...@dia.uniroma3.it> wrote: > Hi Simone and all, > > > On 19/02/2012 22:12, Simone Tripodi wrote: >> >> Hi (and sorry for the late) >> >> I personally don't see the reason to be open to *Operations until >> *Monoid (actually, wrongly, *Weight) until there is the real need of. >> >> Anyway, please share a patch in the issue you filled - code talks much >> better, I could finally see what I am currently missing ;) > > > I uploaded a patch on JIRA[1] as requested. I hope that helps convincing you > ;) > > Ciao, > Claudio > > [1] > https://issues.apache.org/jira/browse/SANDBOX-395?focusedCommentId=13212017&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13212017 > > >> >> looking forward to it! >> -Simo >> >> http://people.apache.org/~simonetripodi/ >> http://simonetripodi.livejournal.com/ >> http://twitter.com/simonetripodi >> http://www.99soft.org/ >> >> >> >> On Sun, Feb 19, 2012 at 5:05 PM, Claudio Squarcella >> <squar...@dia.uniroma3.it> wrote: >>> >>> Hi, >>> >>> >>>>> * Doubles can also be multiplied, but so far we did not need to >>>>> include that in our stack of operations and properties. If we ever >>>>> need to do so, it will be enough to create another interface >>>>> extending OrderedMonoid and change the implemented interface in >>>>> DoubleWeightOperations. >>>> >>>> isn't it a different monoid? I mean, multiplier operator, the 1 >>>> identifier and real numbers are a monoid, or my math became terribly >>>> bad? :P >>> >>> >>> you're right! Your math is cool don't worry :) >>> >>> But see, maybe we could let it implement both an "addiction monoid" and a >>> "multiplication monoid". We could even create Addition (and later maybe >>> Multiplication?) as interface extending Monoid, so that we also solve the >>> other aspect pointed out by Axel days ago: the Monoid would offer a >>> generic >>> "applyOperation", while Addition would wrap it as "sum" (and >>> Multiplication >>> as "multiply"). Cool? >>> >>> >>>>> * Also, there might be properties and/or operations that are unrelated >>>>> to each other, hence DoubleWeightOperations might implement more >>>>> than one interface in the future. >>>> >>>> that sounds good, anyway before to apply any potential improvement >>>> because "users may need of XXX" I'd want to make sure that custom >>>> behaviors can be applied to our APIs just estending existing >>>> component, rather than blindly provide potential features we don't >>>> need. >>>> >>>> I mean... if we do have the real need of having more operations than >>>> the OrderedMonoid already provides, so go for it; otherwise, users >>>> shall be able to define their on *Operator by extending ours and >>>> implementing their custom interface. >>> >>> >>> then we could use the pattern *WeightBaseOperations (e.g. >>> DoubleWeightBaseOperations): so that we developers are free to extend it >>> with more properties over time, as well as the users in their >>> implementations -- and the name is IMHO self-explanatory and unambiguous. >>> >>> In other words: Doubles (as well as the other types) are not *only* >>> monoids. >>> So I feel we would be much more "blind" sticking to the term "monoid" in >>> the >>> implementation: we need more flexibility, and I hope the above >>> *WeightBaseOperations sound good as a candidate. >>> >>> Thank you for the discussion, waiting for further input! >>> Claudio >>> >>> >>>> I would be to support the minimum extensible set of features rather >>>> than supporting all the potential cases, unless we really have the >>>> practical need of them to implement new algos. >>>> >>>> Thoughts? >>>> -Simo >>>> >>>> http://people.apache.org/~simonetripodi/ >>>> http://simonetripodi.livejournal.com/ >>>> http://twitter.com/simonetripodi >>>> http://www.99soft.org/ >>>> >>>> >>>> >>>> On Sun, Feb 19, 2012 at 2:59 PM, Claudio Squarcella >>>> <squar...@dia.uniroma3.it> wrote: >>>>> >>>>> Hello Simone, >>>>> >>>>> >>>>>> It would be much more naturally to my hears hearing it as >>>>>> BigDecimalOrderedMonoid, doesn't it? >>>>> >>>>> >>>>> you have a valid point. However my intention is to decouple >>>>> implementations >>>>> from underlying interfaces, because they might evolve and grow over >>>>> time. >>>>> >>>>> Let me give you two examples: >>>>> >>>>> * Doubles can also be multiplied, but so far we did not need to >>>>> include that in our stack of operations and properties. If we ever >>>>> need to do so, it will be enough to create another interface >>>>> extending OrderedMonoid and change the implemented interface in >>>>> DoubleWeightOperations. >>>>> * Also, there might be properties and/or operations that are unrelated >>>>> to each other, hence DoubleWeightOperations might implement more >>>>> than one interface in the future. >>>>> >>>>> How does that sound? >>>>> >>>>> 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 >>>> >>> -- >>> 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 >> > > -- > 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
