Design behind Moose-Algos-Graph

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Design behind Moose-Algos-Graph

Peter Uhnak
Hi,

I'm curious about the design decisions behind Moose Graph Algorithms.

Basically each algorithm (or at least many of them) has their own
separate class for edges and/or vertices.
This in theory makes the code more descriptive, however it also makes
integration between various algorithms much harder, because now if I
want to run two different algorithms on a single graph I have to
convert them to the appropriate format.

Wouldn't it make more sense to have the necessary behavior pluggable
and have only a single representation of a graph?

I'm sure there some other benefits to the current approach, however I
do not see them.

So all in all I would like to have a perhaps more functional (as in
function) approach, as that more closely matches the mathematics
behind the algorithm(s).

Peter
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Design behind Moose-Algos-Graph

Anne Etien
Hi,

I would love that. But I was not there when the design decisions have been made.

I don’t follow your last paragraph. My point of view is that it should remain as much as possible object oriented code.

Anne

> Le 19 déc. 2015 à 16:14, Peter Uhnák <[hidden email]> a écrit :
>
> Hi,
>
> I'm curious about the design decisions behind Moose Graph Algorithms.
>
> Basically each algorithm (or at least many of them) has their own
> separate class for edges and/or vertices.
> This in theory makes the code more descriptive, however it also makes
> integration between various algorithms much harder, because now if I
> want to run two different algorithms on a single graph I have to
> convert them to the appropriate format.
>
> Wouldn't it make more sense to have the necessary behavior pluggable
> and have only a single representation of a graph?
>
> I'm sure there some other benefits to the current approach, however I
> do not see them.
>
> So all in all I would like to have a perhaps more functional (as in
> function) approach, as that more closely matches the mathematics
> behind the algorithm(s).
>
> Peter
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.list.inf.unibe.ch/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Design behind Moose-Algos-Graph

demarey
In reply to this post by Peter Uhnak
Hi,

Le 19 déc. 2015 à 16:14, Peter Uhnák a écrit :

> Hi,
>
> I'm curious about the design decisions behind Moose Graph Algorithms.
>
> Basically each algorithm (or at least many of them) has their own
> separate class for edges and/or vertices.
> This in theory makes the code more descriptive, however it also makes
> integration between various algorithms much harder, because now if I
> want to run two different algorithms on a single graph I have to
> convert them to the appropriate format.
Yes, I got the same problem.

>
> Wouldn't it make more sense to have the necessary behavior pluggable
> and have only a single representation of a graph?
>
> I'm sure there some other benefits to the current approach, however I
> do not see them.

For some algorithms, it is convenient to have specific nodes to hold data related to nodes (e.g. weight) or temporary data needed for the algorithm itself.

> So all in all I would like to have a perhaps more functional (as in
> function) approach, as that more closely matches the mathematics
> behind the algorithm(s).

Indeed, there are other ways to do that and it could be a good idea to test another implementation.
What is bad with specific nodes and edges is that it does not scale if you have big graphs. It would be good to reuse the graph of your domain.
Maybe you can start to implement a new version of the algorithms you need that way. Then, we can evaluate pros and cons of both approaches.

Christophe
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

smime.p7s (5K) Download Attachment