Speed-up of the MNDS

[mbuzdalov]

In this branch, I speed up this repository's implementation of Merge Non-Dominated Sorting by some constant factor by writing the tightest loop better.

I have also added a simple benchmarking code which compares the performance of the mentioned implementation with its equivalent in mbuzdalov/non-dominated-sorting. The comparison results (on a certain fixed laptop) are as follows:

n	d	Moreno old	Moreno new	Buzdalov
10000	5	0.021	0.019	0.023
30000	5	0.148	0.131	0.186
100000	5	1.46	1.20	2.3
10000	10	0.023	0.023	0.016
30000	10	0.130	0.130	0.114
100000	10	1.02	1.01	0.88

Here, "Moreno old" is the state in master, "Moreno new" is the state of this PR, "Buzdalov" is the BitSetImplementation from my repo. The fastest result in each row is bold.

We can see that "Moreno new" strictly dominates "Moreno old". The comparison with "Buzdalov" is more involved: for dimension 5, the latter is worse, while for dimension 10, the latter is better. The exact reason is not yet known to me, but, most probably, this is due to wordRanking: for smaller dimensions it helps, for larger ones it is a useless overhead.

P.S.1: Here, "Buzdalov" is not the same as ExperimentalFastNonDominanceRanking. This is me having implemented a (so far simplified) MNDS on my own using stock bitsets.

[codecov-io]

Codecov Report

Merging #386 into master will increase coverage by 0.1%. The diff coverage is 92.85%.

@@             Coverage Diff             @@
##             master     #386     +/-   ##
===========================================
+ Coverage     12.03%   12.13%   +0.1%     
- Complexity     1211     1216      +5     
===========================================
  Files           507      507             
  Lines         25641    25637      -4     
  Branches       3633     3633             
===========================================
+ Hits           3085     3111     +26     
+ Misses        22430    22400     -30     
  Partials        126      126

Impacted Files	Coverage Δ	Complexity Δ
...component/ranking/impl/util/MNDSBitsetManager.java	65.95% <92.85%> (+5.75%)	20 <0> (ø)	:arrow_down:
...a/jmetal/operator/crossover/impl/HUXCrossover.java	59.25% <0%> (-11.12%)	6% <0%> (-1%)
.../uma/jmetal/util/measure/impl/CountingMeasure.java	85.71% <0%> (-7.15%)	13% <0%> (-1%)
...a/jmetal/operator/crossover/impl/PMXCrossover.java	71.66% <0%> (+1.66%)	11% <0%> (-1%)	:arrow_down:
...c/main/java/org/uma/jmetal/util/SolutionUtils.java	59.25% <0%> (+1.85%)	19% <0%> (+1%)	:arrow_up:
...l/operator/mutation/impl/SimpleRandomMutation.java	69.56% <0%> (+4.34%)	6% <0%> (+1%)	:arrow_up:
...a/jmetal/algorithm/multiobjective/abyss/ABYSS.java	90.26% <0%> (+6.63%)	53% <0%> (+4%)	:arrow_up:
...tal/operator/mutation/impl/NonUniformMutation.java	50% <0%> (+23.91%)	7% <0%> (+2%)	:arrow_up:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 190b56b...0947876. Read the comment docs.

[matthieu-vergne]

If you are the author of something we publish, you should be part of the authors too (unless you refuse). So you will have your word on that. But if you are the one providing the code, just name the class as you see fit.

[mbuzdalov]

I have dropped all the comments on the name, since Antonio mentioned that the algorithm is nearly published in a journal with the present name.