Reversion: stop deep copying population, just save curr_u
for OptimizationState
construction
#734
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Regarding my previous PRs fixed user
trace!
overload compat. Bothx
and user records now saved #702 and check identity instead of equality #732, I think they were mistaken because of my own unclear thinking about whydt["x"]
needed to be saved via the defaultEvolutionary.trace!
overload.I was operating from the perspective of my own uncommon workflow, where I accumulate "feasible" optimization solutions with each iteration, so I overload the
trace!
to save deep copies of all these feasible solutions, so that the trace acts as a permanent record.However, this is likely much different from the typical use case, where only the most recent
OptimizationState
is relevant for any user-injected callback. So a reference tocurr_u
as it is used in the callback interface_cb
is fine, and in-fact preferred in most cases to minimize memory footprint.Therefore, I have changed the
Evolutionary.trace!
overload to just save a reference the last element of the population, under the key "curr_u
", in line with how the trace was previously being accessed within_cb
. This also clarifies the code by making the reason for thetrace!
overload more transparent.Any further trace functionality that a user might need, like in my own use case, should be left for the user to define via
trace!
overload. This keeps this package and its default settings tailored to the typical use case.contributor guidelines, in particular the SciML Style Guide and
COLPRAC.
Apologies, should have thought more carefully before making the previous PRs.