Sorry, I was on my phone before when I sent that. Let me elaborate a
bit more. I would just allow the weights to be of any type. However,
you can create two different types of scenarios where you either use a
Comparable derivative or you use whatever you want, but you have to
supply a custom Comparator.
On Sun, Dec 11, 2011 at 8:01 PM, James Carman
<james@carmanconsulting.com> wrote:
> I wouldn't restrict the weight to Comparable. What if the user wanted to
> provide their own Comparator?
>
> On Dec 11, 2011 7:07 PM, "Claudio Squarcella" <squarcel@dia.uniroma3.it>
> wrote:
>>
>> Hi all,
>>
>> I explored a bit more the (rather philosophical) dilemma that came from a
>> thread from last week, quoted below
>>>
>>> One step further. A weight is not necessarily a double: in some cases not
>>> even a number, but rather a "comparable" of some sort. So I would suggest to
>>> make use of generics in some way, possibly the smartest. Suggestions are
>>> welcome :)
>>
>>
>> The question is: *what do we mean by weight when dealing with graphs?*
>>
>> "Real number" is a standard answer in graph theory: see, e.g.,
>> http://www.math.jussieu.fr/~jabondy/books/gtwa/pdf/chapter1.pdf (pag. 15).
>> What we have now in the code is a {{getWeight()}} method that returns a
>> double. That serves well for all the algorithms currently implemented, and
>> probably for many more to come. However it is also true that:
>>
>> * some domains of interest and/or algorithms might be more restrictive
>> on the type and sign of "real number" for the weights: integers,
>> nonnegative rationals, etc.
>> * strictly speaking, the basic operations associated with weights are
>> usually just a few. Comparison and sum are enough at least for the
>> algorithms implemented so far in the project (please correct me if I
>> am wrong). Maybe scaling? Additive inverse?
>> * each algorithm is aware of the subset of required operations. E.g.
>> Prim's algorithm for minimum spanning trees only requires edge
>> weights to be comparable, so they could even be Strings or whatever...
>> * some very abstract user might want to use a new class (not
>> necessarily a number) as a weight, provided that it meets the
>> requirements of the domain.
>>
>> So here is a highlevel view of what I propose:
>>
>> * the basic weight is nothing more than a {{Comparable}}, which is
>> hopefully generic enough;
>> * where needed, algorithms define more specific constraints on the
>> input graph in their signature (e.g. Dijkstra can use {{Double}}).
>>
>>
>> Looking forward for comments,
>> Claudio
>>
>> 
>> Claudio Squarcella
>> PhD student at Roma Tre University
>> Email address: squarcel@dia.uniroma3.it
>> Phone: +390657333215
>> Fax: +390657333612
>> http://www.dia.uniroma3.it/~squarcel
>>
>>
>> 
>> To unsubscribe, email: devunsubscribe@commons.apache.org
>> For additional commands, email: devhelp@commons.apache.org
>>
>

To unsubscribe, email: devunsubscribe@commons.apache.org
For additional commands, email: devhelp@commons.apache.org
