commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: [Graph] On graph weight type(s)
Date Sun, 12 Feb 2012 21:39:00 GMT
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
<marco.speranza79@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 <marco.speranza79@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


Mime
View raw message