commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claudio Squarcella <squar...@dia.uniroma3.it>
Subject Re: [graph] renaming weight operations
Date Sun, 19 Feb 2012 16:05:08 GMT
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


Mime
View raw message