Make sure responses with the same keys result in the same response structure
Closed this issue · 1 comments
lisv commented
- Currently there is a problem with the response object structures. This is mainly visible in the clustering fitness functions, where individuals which have the same keys are put in an entirely different clustering object (while they should be in the same clustering object). The issue causes response objects from individuals (with the same keys and values) to be classified as different response structures, while they should be the same.
- This is possibly due to the response objects being stored as String objects (in a map), so this is the first thing to check.
lisv commented
Three problems related to this were found and solved:
- Sometimes there are structures with no clusters -> This is due to the fact that all structures are stored, but not all individuals are clustered (this happens once every X generation, in the meantime individuals are compared to the mean/radius of the existing clusters). Besides looking funny, this is not a problem.
- Sometimes the (exact) same individuals are not in the same cluster while they should be. This is fixed by adjusting the jump in agglomerative clustering when all individuals are the same.
- Sometimes the same individual (same feature vector) has a different response structure. This occurs when there is an empty object (and possibly an empty array, although not seen yet) in the structure, which is not placed in a feature vector. These empty objects so far only occur from when they are sent in a request, therefore making this part of a different issue (not using request keys/parameters in the feature vector), and will therefore be addressed in that issue.
If the server responds with an empty object/array, it is okay that it becomes a different clusterObject since likely different code was covered. However, when it was part of a request that is returned in the response, no other code was covered and different clusterObjects should be avoided.