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
<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: 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
