[
https://issues.apache.org/jira/browse/SANDBOX-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221901#comment-13221901
]
Claudio Squarcella edited comment on SANDBOX-404 at 3/4/12 2:33 PM:
--------------------------------------------------------------------
Hi!
First things first:
My idea is to completely get rid of {{Monoid}}, in favor of a group of
interfaces directly representing operations. In the specific case, {{Addition}}
would immediately "take its place" not semantically but *functionally*, to
cover algorithm needs -- indeed so far we compute "additions" and not generic
"monoid operations", so that would also increase consistency and readability.
It would look more or less like this:
{code}
public interface Addition<E>
{
E sum(E e1, E e2);
E zero();
E negate(E e);
}
{code}
In case later we want to add {{Multiplication}} it will be totally independent,
as explained in my first comment above. Something like:
{code}
public interface Multiplication<E>
{
E multiply(E e1, E e2);
E one(); // or "identity()", we'll see
E reciprocal(E e);
}
{code}
As for the signature change, I did it because I would prefer not to stack
interfaces on top of each other like we did with {{Zero}}, {{Semigroup}},
{{Monoid}} and {{OrderedMonoid}}. As long as we can easily write in the
signatures all the individual properties we need (in the example {{Addition}}
and {{Comparator}}) we can avoid to add interfaces like {{ComparableAddition}},
{{ComparableMultiplication}}, {{ComparableAdditionMultiplication}}... see my
point?
Concluding: I can work on {{Addition}} if, and as soon as, we agree.
Ciao,
Claudio
was (Author: claudio.squarcella):
Hi!
First things first:
My idea is to completely get rid of {{Monoid}}, in favor of a group of
interfaces directly representing operations. In the specific case, {{Addition}}
would immediately "take its place" not semantically but *functionally*, to
cover algorithm needs -- they indeed need to apply "addition" and not a generic
"monoid", so that would also increase consistency. It would look more or less
like this:
{code}
public interface Addition<E>
{
E sum(E e1, E e2);
E zero();
E negate(E e);
}
{code}
In case later we want to add {{Multiplication}} it will be totally independent,
as explained in my first comment above. Something like:
{code}
public interface Multiplication<E>
{
E multiply(E e1, E e2);
E one(); // or "identity()", we'll see
E reciprocal(E e);
}
{code}
As for the signature change, I did it because I would prefer not to stack
interfaces on top of each other like we did with {{Zero}}, {{Semigroup}},
{{Monoid}} and {{OrderedMonoid}}. As long as we can easily write in the
signatures all the individual properties we need (in the example {{Addition}}
and {{Comparator}}) we can avoid to add interfaces like {{ComparableAddition}},
{{ComparableMultiplication}}, {{ComparableAdditionMultiplication}}... see my
point?
Concluding: I can work on {{Addition}} if, and as soon as, we agree.
Ciao,
Claudio
> Simplify weight model
> ---------------------
>
> Key: SANDBOX-404
> URL: https://issues.apache.org/jira/browse/SANDBOX-404
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
> Reporter: Simone Tripodi
> Attachments: SANDBOX-404.patch,
> SANDBOX-404_gettingRidOfOrderedMonoid.patch
>
>
> As discussed on {{dev@}}, {{Zero}}, {{Semigroup}} and {{Monoid}} can be
> merged directly in one single interface
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
