@Aneoshun ? what do you think? Can you have a look? I still need to work on the CVT implementation but otherwise, this is essentially your code. Is there a way to check that it is not broken?

@jbmouret the file <sferes/qd/container/cvt.hpp> seems to be missing.
Best,

Where are the robot arm experiments?

Sorry my bad... wrong commit description (I added a robot arm exp, in an experiment repo). This last commit fixes some bugs in the knn and enables using the add() functions outside the usual epoch() function (which was needed for one of my work).

@Aneoshun I will need to work on converting your archive.hpp to the new storage abstraction. Help appreciated (esp. for testing...)

@Aneoshun I thought a lot about the curiosity/novelty scores, which are currently computed in the container. I guess the rationale is that the container knows best how to compute this score depending on its data-structure. However:

• the data-structure is a bit separated from the container in the new version
• I do not like to compute these values when we do not use them (e.g. in map-elites)
• this is not extensible (we need to compute this in every container if we want to use something else)

To me, this should be part of the selector. The selector can use its own knn structure/container (which may be a duplicate, I agree) but it makes more sense to keep this computation outside of the container itself.

What do you think? Should I try to do this?

@jbmouret Regarding the archive.hpp conversion, I have several students starting to use sferes, they will be able to help with the testing.

Regarding the curiosity/novelty score, this is a tough question. I agree with all the points you raised. I am even wondering wheter it would not make more sense to implement it as a modifier. The modifer has access to the container (it can parse the data into its own structure), it can also query which points has been added or not (and thus update the curiosity score). If we implement it using only the common API of the container, this will be quite extensible, and usable by any future container and selector.

What is your opinion regarding this?

A modifier will work but then the 'user' will need to both select the right selector and the right modifier. But at least we would not compute it when we do not need it and we can add new ones if we want.

I found this library for KD-Trees which seems to be very fast and is header-only (with one header): https://github.com/jlblancoc/nanoflann

It could be a good candidate for replacing the one that we have now (if it is faster)..

@Aneoshun @jbmouret what is the status of this PR?

The code is working and it is the branch we are using everyday in my lab. However, it lacks of documentation, this is why it is not merged yet.

I get Checking for ssrc kdtree (KD-tree) : Not found and then the compilation fails (similar errors as in the CI tests/compilation).. Any ideas?

I get Checking for ssrc kdtree (KD-tree) : Not found and then the compilation fails (similar errors as in the CI tests/compilation).. Any ideas?

No worries. I installed libssrckdtree and everything is okay..

Now I am getting the following error:

../examples/ex_qd.cpp:169:26:   required from here
../sferes/qd/container/kdtree_storage.hpp:75:26: error: passing ‘const tree_t {aka const kd_v1_0_8::spatial::kd_tree<std::array<float, 2>, boost::shared_ptr<sferes::phen::Parameters<sferes::gen::EvoFloat<3, Params>, Robot_arm<Params>, Params> >, unsigned char, unsigned int>}’ as ‘this’ argument discards qualifiers [-fpermissive]
                     auto it = _data.find_nearest_neighbor(pp, false);

I am using version 1.0.8 of the libssrckdtree..

Yes, the original version of srckdtree has an issue. We use a slightly modified version, that I can send to you by e-mail if needed.
The easy alternative is to switch to the SortBasedStorage storage, which does not require the kdtree. It would be probably better to not use the kdtree storage in the default examples tho.

Yes, the original version of srckdtree has an issue. We use a slightly modified version, that I can send to you by e-mail if needed.

Yes please send it to me. Why did you need to change the library?

The easy alternative is to switch to the SortBasedStorage storage

Will this make things slower?

We implemented the SortBasedStorage to remove this dependency that I did not like for a first-class component of sferes. We used to have the KD-tree library included but I did not like this solution much. If I remember well, this is simply a few lines to adapt to modern compilers.

The SortBasedContainers are a bit slower in low-dimensional behavior space, but this is usually negligible compared to the fitness function evaluation; they can actually be faster in high-dimensional beahvioral space (I did some benchmarks in the past and the sort-based version can be competitive).

However, I do not remember the current state of this SortBasedContainer... We should be careful.