[Networkit] Interface conventions for analytics algorithms

Henning Meyerhenke 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.


Thanks,
Henning

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5316 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.ira.uni-karlsruhe.de/mailman/private/networkit/attachments/20141030/9970ea36/attachment.p7s>


More information about the NetworKit mailing list