Re-use indicators (implemented in C) from eaf package?

[MLopez-Ibanez]

Hi Jakob,

I just became aware of your package.

I wonder if it would be better to avoid duplicating efforts in the implementation of performance indicators (such as IGD, hypervolume and epsilon). I have implemented most in the eaf package (https://mlopez-ibanez.github.io/eaf/reference/index.html) together with normalization, dominance checks, pareto rankin, all implemented in C for speed. If it is undesired to depend on the full eaf package for some reason, it may be worth to move all the metrics to a common package and share the burden of maintaining it.

I'll be happy to know your thoughts on this.

Cheers,

Manuel.

[jakobbossek]

Hi Manuel,

I wonder if it would be better to avoid duplicating efforts in the implementation of performance indicators (such as IGD, hypervolume and epsilon). I have implemented most in the eaf package (https://mlopez-ibanez.github.io/eaf/reference/index.html) together with normalization, dominance checks, pareto rankin, all implemented in C for speed. If it is undesired to depend on the full eaf package for some reason, it may be worth to move all the metrics to a common package and share the burden of maintaining it.

I'll be happy to know your thoughts on this.

Yeah, happy to collaborate and share some (maintenance) work. I was already thinking about outsourcing my indicator implementations into a separate package. We should discuss this in a video call.

Cheers, Jakob

[MLopez-Ibanez]

Yeah, happy to collaborate and share some (maintenance) work. I was already thinking about outsourcing my indicator implementations into a separate package. We should discuss this in a video call.

It is a pity we didn't get a chance to talk about this in Leiden. I'm still planning to split the eaf package in 3 parts at least:

1. A repository of high-quality C/C++ implementations of various common metrics and algorithms that can build command-line tools.
2. An R package that serves as an interface to the C/C++ repository but doesn't require any graphical stuff nor any tidyverse (minimal dependencies). The reason for having a separate repository for the C/C++ code is to allow the possibility of using the same code to build a python package. Currently, the subdirectories under https://github.com/MLopez-Ibanez/eaf/tree/master/src are copied verbatim from a different subversion repository, so it could be replaced by a git submodule.
3. An R package for plotting EAF and other visualizations.

Regarding (1), do you see anything in my implementations that could be improved or replaced by your implementations? For example, the hv code in ecr2 seems to be an older version of the code available in the eaf package.