You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Claudio Squarcella <sq...@dia.uniroma3.it> on 2012/02/19 13:40:58 UTC
[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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [graph] renaming weight operations
Posted by Marco Speranza <ma...@apache.org>.
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 <ma...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
Re: [graph] renaming weight operations
Posted by Simone Tripodi <si...@apache.org>.
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
<sq...@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
>> <sq...@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
>>>> <sq...@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
Re: [graph] renaming weight operations
Posted by Claudio Squarcella <sq...@dia.uniroma3.it>.
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
> <sq...@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
>>> <sq...@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
Re: [graph] renaming weight operations
Posted by Simone Tripodi <si...@apache.org>.
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
<sq...@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
>> <sq...@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
Re: [graph] renaming weight operations
Posted by Claudio Squarcella <sq...@dia.uniroma3.it>.
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
> <sq...@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
Re: [graph] renaming weight operations
Posted by Simone Tripodi <si...@apache.org>.
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
<sq...@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
Re: [graph] renaming weight operations
Posted by Claudio Squarcella <sq...@dia.uniroma3.it>.
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
Re: [graph] renaming weight operations
Posted by Simone Tripodi <si...@apache.org>.
Hi Claudio,
while the idea is fine, we should adopt IMHO a little consistent
naming. Why an OrderedMonoid<BigDecimal> shall be called
BigDecimal*Operations* ? What makes it so different to an
OrderedMonoid<MySuperDuperWeightType> ?
It would be much more naturally to my hears hearing it as
BigDecimalOrderedMonoid, doesn't 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 1:40 PM, Claudio Squarcella
<sq...@dia.uniroma3.it> wrote:
> 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-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