Tamás Nepusz comments

Results 691 comments of


                                            Tamás Nepusz

Sets should be re written using Red Black Trees.

I was wondering whether we should simply make use of many of the existing generic header-only C implementations of sets instead of rolling our own. E.g., here is this one:...

Sets should be re written using Red Black Trees.

oh sorry, I meant to assign this to you; it looks like I was quite tired last night when I did this. Feel free to decide how to go ahead...

Sets should be re written using Red Black Trees.

I would probably create an `igraph_set_t` that has an identical interface to what we have now but uses a well-established generic solution under the hood, preferably optimized for integers.

Sets should be re written using Red Black Trees.

`src/cliques/cliquer/set.h` is a set implemented with bitfields, i.e. if you want to store integers between 0 and `n-1`, you'll need `ceil(n/8)` bytes for that. This fits a very specific use-case...

Sets should be re written using Red Black Trees.

I've looked into the current `igraph_set_t` code a bit to jog my memory. It seems like `igraph_set_t` is currently a "private export", i.e. it is exported from the library but...

Sets should be re written using Red Black Trees.

> the code is bugged so it has to be changed. No problem, if there are bugs, we'd better fix them anyway. > I only need integer sets, so I'll...

Sets should be re written using Red Black Trees.

You can drop the `_reserve()` function if that complicates things; I think it is not needed in this case. Typically, `reserve()`-style functions are used in igraph's API when the data...

Sets should be re written using Red Black Trees.

PR #2313 is still ongoing but it's unclear yet what the outcome will be. Nevertheless, I'm removing the stale label.

Is there any point to the `scale` parameter of `eigenvector_centrality()`?

I think that the primary role of scaling is not to reduce confusion (people will always try to interpret eigenvector centralities in absolute terms no matter how you scale them)...

Is there any point to the `scale` parameter of `eigenvector_centrality()`?

Feel free to go ahead.