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/01/08 18:38:22 UTC
Re: [Graph] On graph weight type(s)
Hi,
On 26/12/2011 22:09, Simone Tripodi wrote:
> Hi Claudio!
>
> just make your proposal and attach it to a jira Issue :)
it took a while (you know, Xmas and stuff) but here it is, with description:
https://issues.apache.org/jira/browse/SANDBOX-356
I hope it looks good -- quite a big patch, so of course all comments are
welcome.
Ciao,
Claudio
> Hope to hear from you soon, all the best!
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
--
Claudio Squarcella
PhD student at Roma Tre University
E-mail address: squarcel@dia.uniroma3.it
Phone: +39-06-57333215
Fax: +39-06-57333612
http://www.dia.uniroma3.it/~squarcel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Graph] On graph weight type(s)
Posted by Claudio Squarcella <sq...@dia.uniroma3.it>.
Hi Simone,
> the patch you mentioned was something I would have asked you, before or later :P
I know I can read your mind :)
> Since we are on topic: is there any particular reason why Zero.zero()
> can not be part of Semigroup interface? Or better: is there any
> benefit we can get from keeping Zero and Semigroup separated?
basically the answer is in the following equation:
Monoid = Semigroup + Zero
And also:
OrderedMonoid = Semigroup + Zero + Comparator
The reason why we built all the stack was to allow fine granularity when
defining properties of weights. E.g. it might happen for some reason
that we need to sum weights without needing to know their "zero" value,
or viceversa. In our current implementations OrderedMonoid takes most of
the space (as expected), but also Zero and Monoid are explicitly used.
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] On graph weight type(s)
Posted by Simone Tripodi <si...@apache.org>.
Hola Claudio,
the patch you mentioned was something I would have asked you, before or later :P
Since we are on topic: is there any particular reason why Zero.zero()
can not be part of Semigroup interface? Or better: is there any
benefit we can get from keeping Zero and Semigroup separated?
TIA,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sun, Feb 12, 2012 at 11:36 PM, Claudio Squarcella
<sq...@dia.uniroma3.it> wrote:
> Hi,
>
>
>>> * the mapping between primitive types and their respective default
>>> *Operations is known and kept somewhere (abstract class, etc);
>>> * each algorithm specifies only once the set of primitive types that
>>> it accepts;
>>> * with a bit of magic (?) we combine the above to provide shortcuts to
>>> the user.
>>
>> +1
>>
>> I think that a mapper can be useful.
>> we can create a default mapper between primitives and *Operations and add
>> a void API like that
>> findMaxFlow( graph ).from( a ).to( g ).applying<Algorithm>( void ).
>> we can choose the correct Operation mappimng directly on the default
>> constructor using our mapper.
>>
>> so for the primitives Integer, Double etc, the user doesn't have to
>> specify anything.
>
>
> I thought about something similar. But I finally see two downsides:
>
> * we would need to use reflection for generics or some better
> alternative to actually understand the generic type of weight and
> map it to the appropriate *Operations,
> * we should throw an exception when non-primitive weights are
> incorrectly passed without a handler.
>
> Now that I have a clearer picture in mind I'm almost convinced to give up...
>
> Anyway, expect a patch soon from me that at least incorporates suggestions
> on new names for primitive implementations and variable names ;)
>
> 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] On graph weight type(s)
Posted by Claudio Squarcella <sq...@dia.uniroma3.it>.
Hi,
>> * the mapping between primitive types and their respective default
>> *Operations is known and kept somewhere (abstract class, etc);
>> * each algorithm specifies only once the set of primitive types that
>> it accepts;
>> * with a bit of magic (?) we combine the above to provide shortcuts to
>> the user.
> +1
>
> I think that a mapper can be useful.
> we can create a default mapper between primitives and *Operations and add a void API like that
> findMaxFlow( graph ).from( a ).to( g ).applying<Algorithm>( void ).
> we can choose the correct Operation mappimng directly on the default constructor using our mapper.
>
> so for the primitives Integer, Double etc, the user doesn't have to specify anything.
I thought about something similar. But I finally see two downsides:
* we would need to use reflection for generics or some better
alternative to actually understand the generic type of weight and
map it to the appropriate *Operations,
* we should throw an exception when non-primitive weights are
incorrectly passed without a handler.
Now that I have a clearer picture in mind I'm almost convinced to give up...
Anyway, expect a patch soon from me that at least incorporates
suggestions on new names for primitive implementations and variable names ;)
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] On graph weight type(s)
Posted by Simone Tripodi <si...@apache.org>.
Hi *,
while the idea is fine, it is not clear to me how you intend
implementing it. Please fill an issue and attach a patch so we can
discuss also about the "how" and not only "what" :)
best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sun, Feb 12, 2012 at 10:26 PM, Marco Speranza
<ma...@gmail.com> wrote:
> Hi guys,
>
>> * the mapping between primitive types and their respective default
>> *Operations is known and kept somewhere (abstract class, etc);
>> * each algorithm specifies only once the set of primitive types that
>> it accepts;
>> * with a bit of magic (?) we combine the above to provide shortcuts to
>> the user.
>
> +1
>
> I think that a mapper can be useful.
> we can create a default mapper between primitives and *Operations and add a void API like that
> findMaxFlow( graph ).from( a ).to( g ).applying<Algorithm>( void ).
> we can choose the correct Operation mappimng directly on the default constructor using our mapper.
>
> so for the primitives Integer, Double etc, the user doesn't have to specify anything.
>
> for a graph that uses a custom weight's type, the user can use the findMaxFlow( graph ).from( a ).to( g ).applying<Algorithm>( OrderMonoid ) ) API.
>
> WDYT ?
>
> ciao
>
>
> --
> Marco Speranza <ma...@gmail.com>
>
> Flickr: http://www.flickr.com/photos/marcosperanza79/
> Google Code: http://code.google.com/u/marco.speranza79/
>
>
>
>
> Il giorno 12/feb/2012, alle ore 21:20, Claudio Squarcella ha scritto:
>
>> Hi Simone,
>>
>>>> Would it be so terrible to maintain such redundancy?
>>> IMHO, yes, because:
>>>
>>> * it has to be applied in each class of algorithms we support;
>>>
>>> * switching to proposed APIs, would proliferate that APIs in each algorithm;
>>>
>>> * weight types are driven by generics, so users cannot bind wrong
>>> weight monoid already at compile time.
>>>
>>> more proposals? :)
>>
>> ok fair enough, you were quite convincing :)
>>
>> Before giving up, one more alternative:
>>
>> * the mapping between primitive types and their respective default
>> *Operations is known and kept somewhere (abstract class, etc);
>> * each algorithm specifies only once the set of primitive types that
>> it accepts;
>> * with a bit of magic (?) we combine the above to provide shortcuts to
>> the user.
>>
>> Note: I don't want to over-engineer, I would just like the user not to specify default *Operations, because that is also redundant from his/her point of view.
>>
>> Ciao and thanks,
>> 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] On graph weight type(s)
Posted by Marco Speranza <ma...@gmail.com>.
Hi guys,
> * the mapping between primitive types and their respective default
> *Operations is known and kept somewhere (abstract class, etc);
> * each algorithm specifies only once the set of primitive types that
> it accepts;
> * with a bit of magic (?) we combine the above to provide shortcuts to
> the user.
+1
I think that a mapper can be useful.
we can create a default mapper between primitives and *Operations and add a void API like that
findMaxFlow( graph ).from( a ).to( g ).applying<Algorithm>( void ).
we can choose the correct Operation mappimng directly on the default constructor using our mapper.
so for the primitives Integer, Double etc, the user doesn't have to specify anything.
for a graph that uses a custom weight's type, the user can use the findMaxFlow( graph ).from( a ).to( g ).applying<Algorithm>( OrderMonoid ) ) API.
WDYT ?
ciao
--
Marco Speranza <ma...@gmail.com>
Flickr: http://www.flickr.com/photos/marcosperanza79/
Google Code: http://code.google.com/u/marco.speranza79/
Il giorno 12/feb/2012, alle ore 21:20, Claudio Squarcella ha scritto:
> Hi Simone,
>
>>> Would it be so terrible to maintain such redundancy?
>> IMHO, yes, because:
>>
>> * it has to be applied in each class of algorithms we support;
>>
>> * switching to proposed APIs, would proliferate that APIs in each algorithm;
>>
>> * weight types are driven by generics, so users cannot bind wrong
>> weight monoid already at compile time.
>>
>> more proposals? :)
>
> ok fair enough, you were quite convincing :)
>
> Before giving up, one more alternative:
>
> * the mapping between primitive types and their respective default
> *Operations is known and kept somewhere (abstract class, etc);
> * each algorithm specifies only once the set of primitive types that
> it accepts;
> * with a bit of magic (?) we combine the above to provide shortcuts to
> the user.
>
> Note: I don't want to over-engineer, I would just like the user not to specify default *Operations, because that is also redundant from his/her point of view.
>
> Ciao and thanks,
> 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] On graph weight type(s)
Posted by Claudio Squarcella <sq...@dia.uniroma3.it>.
Hi Simone,
>> Would it be so terrible to maintain such redundancy?
> IMHO, yes, because:
>
> * it has to be applied in each class of algorithms we support;
>
> * switching to proposed APIs, would proliferate that APIs in each algorithm;
>
> * weight types are driven by generics, so users cannot bind wrong
> weight monoid already at compile time.
>
> more proposals? :)
ok fair enough, you were quite convincing :)
Before giving up, one more alternative:
* the mapping between primitive types and their respective default
*Operations is known and kept somewhere (abstract class, etc);
* each algorithm specifies only once the set of primitive types that
it accepts;
* with a bit of magic (?) we combine the above to provide shortcuts to
the user.
Note: I don't want to over-engineer, I would just like the user not to
specify default *Operations, because that is also redundant from his/her
point of view.
Ciao and thanks,
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] On graph weight type(s)
Posted by Simone Tripodi <si...@apache.org>.
Hola,
> Would it be so terrible to maintain such redundancy?
IMHO, yes, because:
* it has to be applied in each class of algorithms we support;
* switching to proposed APIs, would proliferate that APIs in each algorithm;
* weight types are driven by generics, so users cannot bind wrong
weight monoid already at compile time.
more proposals? :)
best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Graph] On graph weight type(s)
Posted by Claudio Squarcella <sq...@dia.uniroma3.it>.
Hello Marco,
>> I understand and agree with you about your doubts - I don't have a
>> strong idea, anyway I wouldn't take the *Handler as first choice,
>> since it does not drive users to an event-handler alike programming
>> model, rather *Operations makes more sense...
>
> +1
c00l :)
> Furthermore I think that name of classes are congruent. In my opinion
> Monoid, OrderMonoid and Semigroup are the right names
I agree.
> findMaxFlow( graph ).from( a ).to( g
> ).applyingEdmondsKarp.withWeightOperation( new IntegerOperation() ) or
> something like that.
I would be more radical (chic) and add one shortcut for each primitive
weight type allowed, e.g:
findMaxFlow( graph ).from( a ).to( g
).applyingEdmondsKarp().usingWeightsAsIntegers()
findMaxFlow( graph ).from( a ).to( g
).applyingEdmondsKarp().usingWeightsAsDoubles()
[...]
I know it's damn redundant. It would be nice to have a better shortcut
to automagically use primitive weight operations when available and
require an explicit *Operations otherwise, but it's not an easy task
(not for me at least).
Note also that some algorithms may impose limits on the actual types
(e.g. Ford-Fulkerson may not terminate with irrational numbers...
although with floating point representation I guess we never face that
risk), so creating explicit shortcuts could also reflect such constraints.
Would it be so terrible to maintain such redundancy?
--
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] On graph weight type(s)
Posted by Marco Speranza <ma...@gmail.com>.
Hi all,
> I understand and agree with you about your doubts - I don't have a
> strong idea, anyway I wouldn't take the *Handler as first choice,
> since it does not drive users to an event-handler alike programming
> model, rather *Operations makes more sense...
+1
Furthermore I think that name of classes are congruent. In my opinion Monoid, OrderMonoid and Semigroup are the right names . In order to help the users, we can add some fluent api
i.e.:
findMaxFlow( graph ).from( a ).to( g ).applyingEdmondsKarp.withWeightOperation( new IntegerOperation() ) or something like that.
Ciao
--
Marco Speranza <ma...@gmail.com>
Flickr: http://www.flickr.com/photos/marcosperanza79/
Google Code: http://code.google.com/u/marco.speranza79/
Il giorno 11/feb/2012, alle ore 21:19, Simone Tripodi ha scritto:
> Ciao Claudio!
>
> I understand and agree with you about your doubts - I don't have a
> strong idea, anyway I wouldn't take the *Handler as first choice,
> since it does not drive users to an event-handler alike programming
> model, rather *Operations makes more sense...
>
> Let's take some time to think about it, excellent catch anyway :)
>
> best,
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Sat, Feb 11, 2012 at 8:53 PM, Claudio Squarcella
> <sq...@dia.uniroma3.it> wrote:
>> Hi,
>>
>>
>>> Maybe one last effort can be made to come up with more understandable
>>> names (e.g. for a user that does not know what a Semigroup or Monoid is).
>>> Suggestions are welcome.
>>
>>
>> I exhume this thread because I am still convinced that the "weight
>> architecture" would benefit from a bit of renaming. It is probably not the
>> case to touch mathematical concepts (Semigroup, Monoid), but rather the
>> actual implementations and/or variable names. Consider that with the current
>> fluent API the user has to deal with this stuff explicitly, specifying the
>> appropriate "handler" for weights.
>>
>> So for example all primitive implementations[1] would change their name from
>> FooWeight to something like FooWeightHandler, or FooWeightOperations, or
>> something like that. Variable names (like in [2]) would change from e.g.
>> orderedMonoid to weightHandler, weightOperations, etc.
>>
>> Any preference?
>>
>> Ciao
>> Claudio
>>
>> [1]
>> http://svn.apache.org/viewvc/commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/weight/primitive/
>> [2] line 64:
>> http://svn.apache.org/viewvc/commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/shortestpath/DefaultShortestPathAlgorithmSelector.java?view=markup
>>
>>
>> --
>> Claudio Squarcella
>> PhD student at Roma Tre University
>> E-mail address: squarcel@dia.uniroma3.it
>> Phone: +39-06-57333215
>> Fax: +39-06-57333612
>> http://www.dia.uniroma3.it/~squarcel
>>
>>
>> ---------------------------------------------------------------------
>> 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] On graph weight type(s)
Posted by Simone Tripodi <si...@apache.org>.
Ciao Claudio!
I understand and agree with you about your doubts - I don't have a
strong idea, anyway I wouldn't take the *Handler as first choice,
since it does not drive users to an event-handler alike programming
model, rather *Operations makes more sense...
Let's take some time to think about it, excellent catch anyway :)
best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sat, Feb 11, 2012 at 8:53 PM, Claudio Squarcella
<sq...@dia.uniroma3.it> wrote:
> Hi,
>
>
>> Maybe one last effort can be made to come up with more understandable
>> names (e.g. for a user that does not know what a Semigroup or Monoid is).
>> Suggestions are welcome.
>
>
> I exhume this thread because I am still convinced that the "weight
> architecture" would benefit from a bit of renaming. It is probably not the
> case to touch mathematical concepts (Semigroup, Monoid), but rather the
> actual implementations and/or variable names. Consider that with the current
> fluent API the user has to deal with this stuff explicitly, specifying the
> appropriate "handler" for weights.
>
> So for example all primitive implementations[1] would change their name from
> FooWeight to something like FooWeightHandler, or FooWeightOperations, or
> something like that. Variable names (like in [2]) would change from e.g.
> orderedMonoid to weightHandler, weightOperations, etc.
>
> Any preference?
>
> Ciao
> Claudio
>
> [1]
> http://svn.apache.org/viewvc/commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/weight/primitive/
> [2] line 64:
> http://svn.apache.org/viewvc/commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/shortestpath/DefaultShortestPathAlgorithmSelector.java?view=markup
>
>
> --
> Claudio Squarcella
> PhD student at Roma Tre University
> E-mail address: squarcel@dia.uniroma3.it
> Phone: +39-06-57333215
> Fax: +39-06-57333612
> http://www.dia.uniroma3.it/~squarcel
>
>
> ---------------------------------------------------------------------
> 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] On graph weight type(s)
Posted by Simone Tripodi <si...@apache.org>.
Ciao Claudio,
>
> yes that would work (inverse should be replaced with negate, not
> reciprocal). We actually thought of commons-math before: it would feel like
> home for our little stack of interfaces (Semigroup, Monoid, etc).
>
+1
> However my question was more on the semantics for class and variable names.
> Any idea?
>
Not yet :(
all the best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Graph] On graph weight type(s)
Posted by Claudio Squarcella <sq...@dia.uniroma3.it>.
Hello Axel,
> Wouldn't it be better to use the same method signatures like in
> commons-math FieldElement?
> http://commons.apache.org/math/apidocs/org/apache/commons/math/FieldElement.html#reciprocal%28%29
>
> reciprocal instead of inverse and
> add instead of append?
yes that would work (inverse should be replaced with negate, not
reciprocal). We actually thought of commons-math before: it would feel
like home for our little stack of interfaces (Semigroup, Monoid, etc).
However my question was more on the semantics for class and variable
names. Any idea?
Thank you :)
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] On graph weight type(s)
Posted by Axel <ax...@gmail.com>.
On Sat, Feb 11, 2012 at 8:53 PM, Claudio Squarcella <
squarcel@dia.uniroma3.it> wrote:
> ....
> Any preference?
>
Wouldn't it be better to use the same method signatures like in
commons-math FieldElement?
http://commons.apache.org/math/apidocs/org/apache/commons/math/FieldElement.html#reciprocal%28%29
reciprocal instead of inverse and
add instead of append?
--
Axel Kramer
Re: [Graph] On graph weight type(s)
Posted by Claudio Squarcella <sq...@dia.uniroma3.it>.
Hi,
> Maybe one last effort can be made to come up with more understandable
> names (e.g. for a user that does not know what a Semigroup or Monoid
> is). Suggestions are welcome.
I exhume this thread because I am still convinced that the "weight
architecture" would benefit from a bit of renaming. It is probably not
the case to touch mathematical concepts (Semigroup, Monoid), but rather
the actual implementations and/or variable names. Consider that with the
current fluent API the user has to deal with this stuff explicitly,
specifying the appropriate "handler" for weights.
So for example all primitive implementations[1] would change their name
from FooWeight to something like FooWeightHandler, or
FooWeightOperations, or something like that. Variable names (like in
[2]) would change from e.g. orderedMonoid to weightHandler,
weightOperations, etc.
Any preference?
Ciao
Claudio
[1]
http://svn.apache.org/viewvc/commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/weight/primitive/
[2] line 64:
http://svn.apache.org/viewvc/commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/shortestpath/DefaultShortestPathAlgorithmSelector.java?view=markup
--
Claudio Squarcella
PhD student at Roma Tre University
E-mail address: squarcel@dia.uniroma3.it
Phone: +39-06-57333215
Fax: +39-06-57333612
http://www.dia.uniroma3.it/~squarcel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Graph] On graph weight type(s)
Posted by Claudio Squarcella <sq...@dia.uniroma3.it>.
Hi all,
the generic implementation of weights is finally completed, at least for
currently implemented algorithms requiring weights. Check out the latest
version of [graph] for details, and the related issue for description of
changes:
https://issues.apache.org/jira/browse/SANDBOX-356
Maybe one last effort can be made to come up with more understandable
names (e.g. for a user that does not know what a Semigroup or Monoid
is). Suggestions are welcome.
Thank you,
Claudio
On 08/01/2012 18:43, Simone Tripodi wrote:
> Hola Claudio,
>
> I just saw the issue - flawless report! - just give me the time to
> process it and I'll let you know!
>
> best,
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Sun, Jan 8, 2012 at 6:38 PM, Claudio Squarcella
> <sq...@dia.uniroma3.it> wrote:
>> Hi,
>>
>>
>> On 26/12/2011 22:09, Simone Tripodi wrote:
>>> Hi Claudio!
>>>
>>> just make your proposal and attach it to a jira Issue :)
>>
>> it took a while (you know, Xmas and stuff) but here it is, with description:
>> https://issues.apache.org/jira/browse/SANDBOX-356
>>
>> I hope it looks good -- quite a big patch, so of course all comments are
>> welcome.
>>
>> Ciao,
>> Claudio
>>
>>
>>
>>> Hope to hear from you soon, all the best!
>>> -Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>>
>> --
>> Claudio Squarcella
>> PhD student at Roma Tre University
>> E-mail address: squarcel@dia.uniroma3.it
>> Phone: +39-06-57333215
>> Fax: +39-06-57333612
>> http://www.dia.uniroma3.it/~squarcel
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
E-mail address: squarcel@dia.uniroma3.it
Phone: +39-06-57333215
Fax: +39-06-57333612
http://www.dia.uniroma3.it/~squarcel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Graph] On graph weight type(s)
Posted by Simone Tripodi <si...@apache.org>.
Hola Claudio,
I just saw the issue - flawless report! - just give me the time to
process it and I'll let you know!
best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sun, Jan 8, 2012 at 6:38 PM, Claudio Squarcella
<sq...@dia.uniroma3.it> wrote:
> Hi,
>
>
> On 26/12/2011 22:09, Simone Tripodi wrote:
>>
>> Hi Claudio!
>>
>> just make your proposal and attach it to a jira Issue :)
>
>
> it took a while (you know, Xmas and stuff) but here it is, with description:
> https://issues.apache.org/jira/browse/SANDBOX-356
>
> I hope it looks good -- quite a big patch, so of course all comments are
> welcome.
>
> Ciao,
> Claudio
>
>
>
>> Hope to hear from you soon, all the best!
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>
> --
> Claudio Squarcella
> PhD student at Roma Tre University
> E-mail address: squarcel@dia.uniroma3.it
> Phone: +39-06-57333215
> Fax: +39-06-57333612
> http://www.dia.uniroma3.it/~squarcel
>
>
>
> ---------------------------------------------------------------------
> 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