Allow custom functions to be used for computing cache keys

[jakobj]

Currently the user can choose between computing a key for the disk cache all arguments and keyword arguments to the decorated function or from the result of evaluating an individual on random numpy arrays and the remaining arguments and keyword arguments.

This PR allows users to specify a function that is used to compute the key for the cache. Two functions are provided by the library: one uses the sympy expression of an individual and the remaining arguments, one the results of evaluating the individual on random numpy arrays and the remaining arguments. In addition the user can define any custom function they like provided its first argument is an individual instance and its return value is a float.

[coveralls]

Coverage decreased (-0.07%) to 94.823% when pulling 4e23405 on jakobj:enh/custom-hash-function-cache into 3b74803 on Happy-Algorithms-League:master.

[coveralls]

Coverage decreased (-0.07%) to 94.823% when pulling c2de328 on jakobj:enh/custom-hash-function-cache into 3b74803 on Happy-Algorithms-League:master.

[mschmidt87]

This is pretty nice. However, in the spirit of trying to not add functionality without a real need: Is there a real need for this? What would be a case where the default option does not work?

[jakobj]

This is pretty nice. However, in the spirit of trying to not add functionality without a real need: Is there a real need for this? What would be a case where the default option does not work?

one use case arises in connection with hurdles: assume that you have two objectives which both measure performance of a plasticity rule over a number of trials (small and large respectively). you want to use the disk cache for both objectives. for the first, you use the normal numpy evaluation check. but then for the second you might actually assign identical fitness values to those individuals which achieve identical fitness on the first objective, since it's very likely that they will have identical fitness on the second as well. this is a less strict equivalence check than numpy evaluation and hence catches more functionally (in terms of fitness on objective) identical individuals.

[jakobj]

ping @mschmidt87

[mschmidt87]

Did you add a test with a custom function? I can't see it, but perhaps I just missed it?

[jakobj]

Did you add a test with a custom function? I can't see it, but perhaps I just missed it?

now i have ;) pls have another look

[mschmidt87]

Thanks. I will approve, but I am thinking that if this implies an API change, shouldn't we change the milestone to 1.0?

[jakobj]

Thanks. I will approve, but I am thinking that if this implies an API change, shouldn't we change the milestone to 1.0?

well, many PRs have changed to API without us bumping to 1.0, and likely many future ones will (see issues). as far as i understand prior to release 1.0 we're technically still in the beta phase, and semantic versioning doesn't require us to bump major version upon API change:

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.
(from https://semver.org/)

[jakobj]

thx! squashed and waiting for travis