commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: [graph] renaming weight operations
Date Tue, 21 Feb 2012 07:39:00 GMT
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
<squarcel@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
>> <squarcel@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
>>>> <squarcel@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-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message