Closeness centrality running without interruption about teneto

[wiheto]

Hi,

Unfortunately the current code in shortest_temporal_paths is currently quite slow in its current implementation, especially for larger networks (exponentially grows with size). I've only really used in on networks about 200 nodes in size and 400 time points. It is something on the todo list to increase the speed.

[wiheto]

So the code should finish eventually, but I can't say how long it will take.

[sopeKhadim]

Thank you for your response,
Can we hope soon that you will improve the performance of the shortest path code for large temporal networks?
I think other measures depend on it, like betweeness.

[wiheto]

Can we hope soon that you will improve the performance of the shortest path code for large temporal networks?

I'll boost it up the priority queue cause it is something I've wanted to fix for sometime.

[zhao-snoe]

Have you solved your problem?At present, I also met the problem of using the same as you in the calculation

[zhao-snoe]

In your article, I saw that you used more than 200 nodes and more than 400 time points. How long did it take you to calculate the closness centrality? I think this may have time-reference significance for my current calculations. Because I calculate 60 nodes, 51 networks, and 10% sparsity. My code is running more than four days without stopping.

[wiheto]

Development on the toolbox stalled this year because of other reasons.

The original article used an older version of this function which was quick, but could not handle larger networks. The speed issue was introduced to the shortest temporal paths function when modifying the rest of the toolbox to being able to handle larger networks.

You can use an older version of the code which should be quicker:

I think the quicker version can be found here: https://github.com/wiheto/teneto/releases/tag/0.3.5

Until then, despite being a high priority when developing this toolbox, this is currently only something which is done in my spare time due to other obligations. I cannot give a time estimate when I can push to complete the the next version where the shortest path estimation will be substantially quicker.

[zhao-snoe]

Thank you for your prompt reply. I will try with the code you recommended.

…

------------------&nbsp;原始邮件&nbsp;------------------ 发件人: "wiheto/teneto" <[email protected]&gt;; 发送时间:&nbsp;2020年12月24日(星期四) 凌晨1:16 收件人:&nbsp;"wiheto/teneto"<[email protected]&gt;; 抄送:&nbsp;"咹靜"<[email protected]&gt;;"Comment"<[email protected]&gt;; 主题:&nbsp;Re: [wiheto/teneto] Closeness centrality running without interruption (#64) Development on the toolbox stalled this year because of other reasons. The original article used an older version of this function which was quick, but could not handle larger networks. The speed issue was introduced to the shortest temporal paths function when modifying the rest of the toolbox to being able to handle larger networks. You can use an older version of the code which should be quicker: I think the quicker version can be found here: https://github.com/wiheto/teneto/releases/tag/0.3.5 Until then, despite being a high priority when developing this toolbox, this is currently only something which is done in my spare time due to other obligations. I cannot give a time estimate when I can push to complete the the next version where the shortest path estimation will be substantially quicker. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[wiheto]

So now I have time to solve this issue. I'm gathering all the issues regarding speed into one issue. Follow #74 for more info about this.