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