{"action":"created","issue":{"url":"https://api.github.com/repos/robertfeldt/BlackBoxOptim.jl/issues/18","labels_url":"https://api.github.com/repos/robertfeldt/BlackBoxOptim.jl/issues/18/labels{/name}","comments_url":"https://api.github.com/repos/robertfeldt/BlackBoxOptim.jl/issues/18/comments","events_url":"https://api.github.com/repos/robertfeldt/BlackBoxOptim.jl/issues/18/events","html_url":"https://github.com/robertfeldt/BlackBoxOptim.jl/pull/18","id":94161182,"number":18,"title":"Fitness-storing Population & friends","user":{"login":"alyst","id":348591,"avatar_url":"https://avatars.githubusercontent.com/u/348591?v=3","gravatar_id":"","url":"https://api.github.com/users/alyst","html_url":"https://github.com/alyst","followers_url":"https://api.github.com/users/alyst/followers","following_url":"https://api.github.com/users/alyst/following{/other_user}","gists_url":"https://api.github.com/users/alyst/gists{/gist_id}","starred_url":"https://api.github.com/users/alyst/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/alyst/subscriptions","organizations_url":"https://api.github.com/users/alyst/orgs","repos_url":"https://api.github.com/users/alyst/repos","events_url":"https://api.github.com/users/alyst/events{/privacy}","received_events_url":"https://api.github.com/users/alyst/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":8,"created_at":"2015-07-09T21:57:40Z","updated_at":"2015-07-11T16:35:55Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/robertfeldt/BlackBoxOptim.jl/pulls/18","html_url":"https://github.com/robertfeldt/BlackBoxOptim.jl/pull/18","diff_url":"https://github.com/robertfeldt/BlackBoxOptim.jl/pull/18.diff","patch_url":"https://github.com/robertfeldt/BlackBoxOptim.jl/pull/18.patch"},"body":"The major goal of the patch is ```FitPopulation{F}``` type that allows storing fitness values within the population and ```rank_by_fitness!()``` that skips the candidates with the defined fitness, which should double the performance of DE.\r\n\r\nThe PR is quite invasive (mostly motivated by the need to have fitness value type known by the population and fitness schema known by the optimization problem) and touches a few core classes:\r\n  * ```FitnessScheme``` is parameterized by fitness value type. The available schemes are ```ScalarFitness{true/false}``` and ```VectorFitness{true/false}``` (this one untested)\r\n  * ```FitnessScheme``` is now accessible from ```OptimizationProblem``` as well as the ```SearchSpace```\r\n  * ```FixedDimProblem``` renamed into ```FunctionBasedProblem``` and ```AnyDimProblem``` into ```FunctionBasedProbelmFamily```. The latter is also not an ```OptimizationProblem``` anymore  --- that's because all the problems the optimizers could solve [currently] are finite dimensional\r\n  * ```FunctionBasedProblem``` is subclassed into ```Bounded``` (optimum is known) and ```Unbounded``` -- the required subtype is determined automatically\r\n  * ```AskTellOptimizer``` abstract type\r\n  * ```Optimizer``` constructors now have access to the ```OptimizationProblem```, therefore passing ```search_space``` through dictionary no longer needed\r\n  * to reduce the GC overhead ```FitPopulation``` maintains a pool of candidates -- no memory allocation in ```ask()/tell!()```, just copying."},"comment":{"url":"https://api.github.com/repos/robertfeldt/BlackBoxOptim.jl/issues/comments/120639012","html_url":"https://github.com/robertfeldt/BlackBoxOptim.jl/pull/18#issuecomment-120639012","issue_url":"https://api.github.com/repos/robertfeldt/BlackBoxOptim.jl/issues/18","id":120639012,"user":{"login":"alyst","id":348591,"avatar_url":"https://avatars.githubusercontent.com/u/348591?v=3","gravatar_id":"","url":"https://api.github.com/users/alyst","html_url":"https://github.com/alyst","followers_url":"https://api.github.com/users/alyst/followers","following_url":"https://api.github.com/users/alyst/following{/other_user}","gists_url":"https://api.github.com/users/alyst/gists{/gist_id}","starred_url":"https://api.github.com/users/alyst/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/alyst/subscriptions","organizations_url":"https://api.github.com/users/alyst/orgs","repos_url":"https://api.github.com/users/alyst/repos","events_url":"https://api.github.com/users/alyst/events{/privacy}","received_events_url":"https://api.github.com/users/alyst/received_events","type":"User","site_admin":false},"created_at":"2015-07-11T16:35:55Z","updated_at":"2015-07-11T16:35:55Z","body":"> Not convinced that VectorFitness is the way to go.\r\n\r\nMaybe it's my misunderstanding of ```aggregate()``` and ```RatioFitnessScheme``` purpose. I wasn't sure how it should be used, so I tried to keep it as intact as possible. But the proposed design of ```FitnessScheme```, I believe, allows for proper comparison of vector fitnesses using the domination ordering throughout the optimization process, the details could be sorted out when we would have some example problems.\r\n\r\nWhat I'm not sure about is whether this PR fits the ideas drafted in ```fitness/fitness_types.jl```. I have no experience of such extensions of fitness concept, so it might require few more design iteration(s).\r\n\r\nAs a side note wrt vector fitness I just thought that the we can use ```NTuple{T,N}``` (introduced recently in v0.4) as the fitness type -- it would act as a vector with a fixed length known at compile time.\r\n\r\n> I'm also a bit hesitant about last_fitness since this makes parallel evaluation very hard.\r\n\r\nThanks for noticing. That was a fragment of the older code. Now I fixed it.\r\n\r\n> ```UnboundedProblem``` and ```BoundedProblem``` more implies whether they have bounding of the search space for me.\r\n\r\nI agree. Are e.g. ```UnknownOptimumProblem``` and ```KnownOptimumProblem``` better?"}}