[Networkit] Interface conventions for analytics algorithms
meyerhenke at kit.edu
Thu Oct 30 07:28:56 CET 2014
Thanks, Christian, for taking the initiative.
Thanks, Florian, for your answers.
> Returning a value directly is usually the by far fastest way that also
> doesn't have the problem of wasting space in the class, the BIG problem
> of returning a non default-constructable type (you need some kind of
> optional-type for that, which can certainly be done, but further
> increases complexity), and dealing with early calls to `getResult()`
> (before the algorithm has executed, it is not obvious how to handle that
> case, while for returnvalues that problem just doesn't exist).
How often do we need very complex return values that could/should not be
the return value of the run method? I'd rather avoid the getters.
> Concerning the function-arguments: You are certainly right with the
> approach to pass several of them in the ctor, I would however recommend
> to leave some room there, since sometimes the benefits of being able to
> call the same functor twice with slightly different arguments might be
> significant: Just think of Dijkstra: If we need to get the distances of
> different places to the same starting-point on the same graph, we would
> profit enormously from being able to pass end-note as argument and
> reusing the structures build so far. OTOH we wouldn't profit in any way
> from reseting the starting-node or the graph, so those should be ctor-args.
This is very important. At quite a few places we have some preprocessing
in the ctor. Then we need the flexibility in the run method to invoke it
for different query parameters. Such a separation of preprocessing/query
must be possible and efficient.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5316 bytes
Desc: S/MIME Cryptographic Signature
More information about the NetworKit