# [Networkit] Refactoring Diameter to the standard interface

Christian Staudt christian.staudt at kit.edu
Tue Feb 9 15:25:37 CET 2016

```Thank you, it works fine now.
C.

> On 29 Jan 2016, at 12:30, Maximilian Vogel <maximilian.vogel at student.kit.edu> wrote:
>
>
>
> On 29.01.2016 12:04, Christian Staudt wrote:
>> As far as I remember, the current exact diameter algorithm is fast enough for all typical inputs, right? Getting a lower and upper bound was important when we did not yet have a good algorithm like that, and is now somewhat obsolete, I think.
> The current exact algorithm just calls Michael's implementation of the sumsweep algorithm with error=0, referred to as DiameterAlgo::estimatedRange and from the resulting tuple it just ignores the upper bound. For weighted graphs, the exact algorithm uses a Dijkstra instance for each node.
>
>>
>> Doesn’t work for me either:
>>
>> In [4]: distance.Diameter(G, distance.DiameterAlgo.Exact).run().getDistance()
>> ---------------------------------------------------------------------------
>> AttributeError                            Traceback (most recent call last)
>> <ipython-input-4-4fedc44e4eed> in <module>()
>> ----> 1 distance.Diameter(G, distance.DiameterAlgo.Exact).run().getDistance()
>>
>> AttributeError: '_NetworKit.Diameter' object has no attribute 'getDistance'
>>
>> This works, but the result looks weird:
>>
>> In [5]: distance.Diameter(G, distance.DiameterAlgo.Exact).run().getDiameter()
>> Out[5]: (9, 0)
>>
>> Anyway, Diameter(G).run().get... should also just work and yield one number as a result.
> Well, getDistance() was a typo. I meant getDiameter(). For algorithms computing a lower and upper bound, one number won't do it.
>
>> Let us know if you were able to figure out what went wrong.
> I was able to fix it, see: https://algohub.iti.kit.edu/parco/NetworKit/NetworKit/changeset/3feae7d76146753a0717dbaa403c82207f6f54b5 <https://algohub.iti.kit.edu/parco/NetworKit/NetworKit/changeset/3feae7d76146753a0717dbaa403c82207f6f54b5>
> The constructor now works for the default case and is more verbose if the correct parameter is not provided.
>
>
>
>>> On 29 Jan 2016, at 11:49, Maximilian Vogel < <mailto:maximilian.vogel at student.kit.edu>maximilian.vogel at student.kit.edu <mailto:maximilian.vogel at student.kit.edu>> wrote:
>>>
>>> I can confirm this, but I don't exactly know, why this happens. The behaviour of the constructor should be discussed anyways.
>>> You can use the entries in the class distance.DiameterAlgo to choose one of the existing algorithms. Currently, distance.DiameterAlgo.Automatic produces the exception. The other options work fine for me. Note that for the option distance.DiameterAlgo.estimatedRange one should supply the additional parameter error (e.g. 0) and for distance.DiameterAlgo.estimatedSamples the desired number of samples (called nSamples).
>>> One example call could be: distance.Diameter(G, distance.DiameterAlgo.Exact).run().getDistance()
>>>
>>> On 29.01.2016 11:36, Christian Staudt wrote:
>>>> For me it doesn’t yet work fine:
>>>>
>>>> In [5]: dia = distance.Diameter(G)
>>>>
>>>> In [6]: dia.run()
>>>> ---------------------------------------------------------------------------
>>>> RuntimeError                              Traceback (most recent call last)
>>>> <ipython-input-6-50e09f02bdc6> in <module>()
>>>> ----> 1 dia.run()
>>>>
>>>> /Users/cls/workspace/NetworKit/networkit/_NetworKit.pyx in _NetworKit.Algorithm.run (networkit/_NetworKit.cpp:6403)()
>>>>     114                         raise RuntimeError("Error, object not properly initialized")
>>>>     115                 with nogil:
>>>> --> 116                         self._this.run()
>>>>     117                 return self
>>>>     118
>>>>
>>>> RuntimeError: should never reach this code as the algorithm should be set correctly in the constructor or fail there
>>>>
>>>> What am I doing wrong?
>>>>
>>>>
>>>>> On 28 Jan 2016, at 16:10, Maximilian Vogel <maximilian.vogel at student.kit.edu <mailto:maximilian.vogel at student.kit.edu>> wrote:
>>>>>
>>>>> I refactored the Diameter class. Although it works fine so far, I still consider it work in progress (documentation, behaviour of the constructor, proper toString-method, ...). I think it's a good opportunity for a code review and suggestions.
>>>>>
>>>>> Changes can be seen here:
>>>>> - https://algohub.iti.kit.edu/parco/NetworKit/NetworKit/changeset/5880040659cc84b05dff0e1b6ea1507cc2efb422 <https://algohub.iti.kit.edu/parco/NetworKit/NetworKit/changeset/5880040659cc84b05dff0e1b6ea1507cc2efb422>
>>>>>
>>>>> Best
>>>>> Max
>>>>>
>>>>> On 27.01.2016 08:35, Henning Meyerhenke wrote:
>>>>>> Christian's suggestion would also be my preference.
>>>>>>
>>>>>> HM
>>>>>>
>>>>>>
>>>>>> Am 26.01.16 um 21:26 schrieb Christian Staudt:
>>>>>>> I recommend to move towards “one class - one measure”, the network
>>>>>>> analysts perspective (rather than “one class - one algorithm”, the
>>>>>>> algorithm engineer’s perspective). So probably Diameter should be one
>>>>>>> class and the computation that .run() performs should be selected in the
>>>>>>> constructor.
>>>>>>>
>>>>>>>
>>>>>>>> On 26 Jan 2016, at 11:36, Maximilian Vogel
>>>>>>>> <maximilian.vogel at student.kit.edu <mailto:maximilian.vogel at student.kit.edu>
>>>>>>>> <mailto:maximilian.vogel at student.kit.edu> <mailto:maximilian.vogel at student.kit.edu>> wrote:
>>>>>>>>
>>>>>>>> This is just a little brainstorming:
>>>>>>>>
>>>>>>>>   * Refactor the different implementations into private methods.
>>>>>>>>     Implement some logic deciding which algorithm to use in the
>>>>>>>>     constructor. The run()-method then calls the right private method.
>>>>>>>>     Retrieve the result with a getter method (always!) returning a pair.
>>>>>>>>   * Expanding on the previous idea: Move the different implementations
>>>>>>>>     into seperate classes and implement a wrapper class for convenient
>>>>>>>>     usage.
>>>>>>>>
>>>>>>>> Those are the two raw designs that came to my mind. The second one
>>>>>>>> seems cleaner, but probably means more work.
>>>>>>>>
>>>>>>>> Any fundamentally different designs? What do you think?
>>>>>>>>
>>>>>>>> Best
>>>>>>>> Max
>>>>>>>>
>>>>>>>>
>>>>>>>> On 25.01.2016 17:58, Christian Staudt wrote:
>>>>>>>>> I have a situation in which it is very inconvenient that the Diameter class does not follow the standard pattern for our analytics algorithms, with parameter initialization in the constructor and a parameter-less run method.
>>>>>>>>> Since several other people either depend or work on Diameter, I’d like to discuss proposals on how to refactor. To be honest I’d also be happy if someone would volunteer to implement the refactoring.
>>>>>>>>>
>>>>>>>>> Chris
>>>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> NetworKit mailing list
>>>>>> NetworKit at ira.uni-karlsruhe.de <mailto:NetworKit at ira.uni-karlsruhe.de>
>>>>>> https://lists.ira.uni-karlsruhe.de/mailman/listinfo/networkit <https://lists.ira.uni-karlsruhe.de/mailman/listinfo/networkit>
>>>>>
>>>>> _______________________________________________
>>>>> NetworKit mailing list
>>>>> NetworKit at ira.uni-karlsruhe.de <mailto:NetworKit at ira.uni-karlsruhe.de>
>>>>> https://lists.ira.uni-karlsruhe.de/mailman/listinfo/networkit <https://lists.ira.uni-karlsruhe.de/mailman/listinfo/networkit>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> NetworKit mailing list
>>>> NetworKit at ira.uni-karlsruhe.de <mailto:NetworKit at ira.uni-karlsruhe.de>
>>>> https://lists.ira.uni-karlsruhe.de/mailman/listinfo/networkit <https://lists.ira.uni-karlsruhe.de/mailman/listinfo/networkit>
>>>
>>> _______________________________________________
>>> NetworKit mailing list
>>> NetworKit at ira.uni-karlsruhe.de <mailto:NetworKit at ira.uni-karlsruhe.de>
>>> https://lists.ira.uni-karlsruhe.de/mailman/listinfo/networkit <https://lists.ira.uni-karlsruhe.de/mailman/listinfo/networkit>
>>
>>
>>
>> _______________________________________________
>> NetworKit mailing list
>> NetworKit at ira.uni-karlsruhe.de <mailto:NetworKit at ira.uni-karlsruhe.de>
>> https://lists.ira.uni-karlsruhe.de/mailman/listinfo/networkit <https://lists.ira.uni-karlsruhe.de/mailman/listinfo/networkit>
>
> _______________________________________________
> NetworKit mailing list
> NetworKit at ira.uni-karlsruhe.de <mailto:NetworKit at ira.uni-karlsruhe.de>
> https://lists.ira.uni-karlsruhe.de/mailman/listinfo/networkit <https://lists.ira.uni-karlsruhe.de/mailman/listinfo/networkit>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ira.uni-karlsruhe.de/mailman/private/networkit/attachments/20160209/9c52a768/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.ira.uni-karlsruhe.de/mailman/private/networkit/attachments/20160209/9c52a768/attachment-0001.sig>
```