[CollEc] New CollEc

[Düben, Christian]

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 at uni-hamburg.de
http://www.christian-dueben.com


-----Original Message-----
From: Thomas Krichel <krichel at openlib.org> 
Sent: Dienstag, 11. August 2020 11:51
To: Düben, Christian <Christian.Dueben at uni-hamburg.de>
Cc: CollEc Run <collec-run at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Example_Graph.png
Type: image/png
Size: 10065 bytes
Desc: Example_Graph.png
URL: <http://lists.openlib.org/pipermail/collec-run/attachments/20200811/037bcb24/attachment.png>