Re: [graph] renaming weight operations
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=13212017page=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.itwrote: 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:
Re: [graph] renaming weight operations
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=13212017page=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
[graph] renaming weight operations
Hi all, following previous discussion on ML I opened a JIRA issue to rename classes/variables related to operations on weights: https://issues.apache.org/jira/browse/SANDBOX-395 I will soon work on it. If there is any last minute suggestion I will be happy to hear that. Ciao, -- 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
Re: [graph] renaming weight operations
Hi Claudio, I will soon work on it. If there is any last minute suggestion I will be happy to hear that. there isn't any suggestion by me... in my point of view your suggestion can be useful and increase the code expressiveness. have a nice day :) -- Marco Speranza marcospera...@apache.org Google Code: http://code.google.com/u/marco.speranza79/ Il giorno 19/feb/2012, alle ore 13:40, Claudio Squarcella ha scritto: Hi all, following previous discussion on ML I opened a JIRA issue to rename classes/variables related to operations on weights: https://issues.apache.org/jira/browse/SANDBOX-395 I will soon work on it. If there is any last minute suggestion I will be happy to hear that. Ciao, -- 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 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [graph] renaming weight operations
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
Re: [graph] renaming weight operations
Hi Cloud/IO :) * 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 * 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. 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
Re: [graph] renaming weight operations
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
Re: [graph] renaming weight operations
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 ;) 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:
