commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claudio Squarcella <squar...@dia.uniroma3.it>
Subject Re: [Graph] On graph weight type(s)
Date Sun, 12 Feb 2012 16:36:35 GMT
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


Mime
View raw message