[Networkit] Interface conventions for analytics algorithms
christian.staudt at kit.edu
Thu Oct 30 15:52:01 CET 2014
A) Getters and alternatives
> 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.
Often. Michael gave an example. For me the standard example is CoreDecomposition. Users may be interested in the core number of a node, the maximum core number or the cores or shells as sets of nodes, all of which come from the same computation. Therefor different getters that present different views on the result.
An alternative to the getters on the algorithm class is to create special result/data classes and move the getters there. Like I did with the Partition object: You now ask the result object for different views, e.g. the number of communities or their sizes. But making these result classes is extra work, I’m not sure when exactly this is the way to go. Anyway you have getters somewhere. The alternative to getters is to return tuples of multiple values….
> Concerning the returnvalues: Could you elaborate on that, since I don't
> really see the problem that this solves, especially since returning more
> than one value is nowadays of acceptable complexity in c++?
… and I am rather against that:
- The user has to remember the order and type of the tuple items.
- Suppose you would like to add something to an existing algorithm and return another result. Adding one more getter is easy, changing the return type of a method that’s already in use means work.
- It’s easy to do it in an ugly way. Sometimes it is understood as an invitation to do what I would call „weirdly stateless OOP“, returning from the run method basically the data content of the object as a tuple of maps of lists or something… :/
> 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.
Yes, but as Michael explained, this can just as well be done by not using the constructor as a run method and not using the run method as a getter. Long computations should not happen unexpectedly, and a long running constructor is unexpected. Here’s the convention I propose:
- constructor: parameter setting, cheap
- run-method: computation, expensive
- getters: queries, cheap
There might be good reasons to deviate from that, so I would not enforce it with a superclass. But mostly it is done for no better reason than „it’s the first thing that came to my mind“. Right now I can’t think of a case where it doesn’t fit - anyone? (@Michael: Even a stopping criterion could just as well be an optional constructor argument.)
B) run-method vs callable objects
> There are lots of places where the stdlib uses `operator()` and
> implements algorithms that way; my personal impression is that
> following stdlib-conventions often ended way nicer with newer
> standards than inventing your own.
> I favor the run method,
> in my opinion MyAlgorithm(parameters)() doesn't look right. Otherwise I think
> we could directly use global functions which is probably not what we want.
I somehow agree with both points. So far I don’t see enough benefits of callable objects to justify all the refactoring work. What would be the big benefit of putting our algorithms in stdlib algorithms? I can’t imagine a case.
> * Instead of a base-class we could just alias std::function which would
> give us structural typing here (the python-fans of you may like
> that, especially since this wouldn't compromise on type-safety)
I don’t really understand this. Can you explain?
> Concerning the complexity of the Python interface: I think we can make this a
> lot easier by returning "self" in the run-method in Python.
Good idea, we should do that so it’s possible to write just one line to get a single result.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the NetworKit