[CollEc] New CollEc

[Thomas Krichel]

  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