In my research I usually apply graph theoretical methods in a geo-spatial context. And in that field I would not consider the two stage procedure a viable choice when compared with properly defined transition functions. I guess that is why I am not a fan. Let me explain how the proposed transition function replaces the two stage procedure without changing the results. Consider the graph attached to this e-mail. The numbers denote the quantity of joint papers. What is the shortest path between A and H? There are three potential connections: A-C-D-H, A-B-E-H and A-B-F-G-H. With the inverse transition function (W_{i,j} = N_{i,j}{-1}) the shortest path would be A-B-F-G-H because its sum of edge weights (1.38) is lower than in the other two cases (1.83 and 2). However, in your two stage binary process this path would have been ruled out in the first stage because there are five authors on it, compared two four authors in the other two options. Your procedure would choose A-C-D-H. It is one of the two shortest paths (A-C-D-H and A-B-E-H) in the binary case. And it is the shorter one among the two when weighted by the number of papers. The proposed transition function W_{i,j} = 1 - (N_{i,j} * 0.001) results in the same shortest path. A-C-D-H (length: 2.994) is shorter than A-B-E-H (length: 2.995) and A-B-F-G-H (length: 3.972). This transition function is the binary application, minimizing the quantity of authors, with a tiny adjustment for the number of papers selecting the shortest path among the binary case options. Is that clear? Christian Düben Research Associate Chair of Macroeconomics Hamburg University Von-Melle-Park 5, Room 3102 20146 Hamburg Germany +49 40 42838 1898 christian.dueben@uni-hamburg.de http://www.christian-dueben.com -----Original Message----- From: Thomas Krichel <krichel@openlib.org> Sent: Dienstag, 11. August 2020 11:51 To: Düben, Christian <Christian.Dueben@uni-hamburg.de> Cc: CollEc Run <collec-run@lists.openlib.org> Subject: Re: New CollEc Düben, Christian writes
I openly admit that I am not a fan of that two stage procedure with an unweighted (binary) first stage and a weighted second stage.
Why not?
However, I see that you really insist on having it in the app.
No, I don't but I want to have it exported. And I prefer to have it in the app, otherwise the data will be literally incredible. Users will look at weight data and seen triangles.
Thus, I came up with a solution that produces the same results as your two stage procedure while being a lot more efficient: W_{i,j} = 1 - (N_{i,j} * 0.001). Unless any two authors published at least 500 papers together this transition function results in the same shortest path as the two stage approach.
I don't understand this, sorry. Will the replace binary paths?
Just like you insist on the above mentioned unweighted-weighted combination, I am not dropping the weighted cases. To evaluate how intuitive the weighted edges are to new users I asked various people to test the app. And nobody struggled with the intuition behind edge weighting. It is the same as requesting the fastest route between two places on Google Maps. To account for your concerns I already set the binary option as the app's default case. Users have to actively tick a box to change from the unweighted (binary) to weighted cases.
Edge weighting is not a problem as long as the users know this.
So, how about you get your optimized unweighted-weighted approach and I keep the weighted edges in the app?
Keep them in the app. I don't have a problem, but we should export binary paths. -- Cheers, Thomas Krichel http://openlib.org/home/krichel skype:thomaskrichel
