You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, emigration and immigration propagators are passed down to the actual propagator and pollinator using the class itself and not an actual instance. The respective propagators are repeatedly instantiated before every new migration step. However, propagators should be instantiated only once (in the __init__).
For real migration (cf. Migrator class), copies of individuals are not allowed. Whenever a worker on an island performs migration, we can thus choose all emigrants from the eligible individuals at once, shuffle them, and then send them away to each respective target island according to the migration topology.
Thus, we only need one emigration propagator for each island that has the number of overall individuals to emigrate to all other islands as its offspring argument. This number can be calculated by summing over the respective row in the migration topology.
It would be possible to instantiate these island-specific emigration propagators on the very top-level in the user script and pass it as a list to the Islands class which assigns each island its specific emigration propagator from this list based on the island index. This has the advantage that the user can set all other arguments required for instantiating the propagator directly.
Alternatively, the emigration propagator could be instantiated in the __init__ method of either the Islands or the Migrator class. This would maybe require an additional kwargs attribute to pass down custom arguments for instantiating the propagator.
This probably also implies that a sending island does not differentiate between target islands when sending emigrants. If we would like to have that, we would need to pass down a (nested) list of num_islands * (num_islands-1) propagators. This would probably be the most general solution which might also work for pollination. However, if we were to choose the emigrants for each target island separately, we would need to take care of deactivating those that are gone before choosing the next ones. This also implies some kind of hierarchy for the target islands (which one gets to choose first?).
Pollination
For pollination, copies of individuals are allowed. To avoid instantiating the emigration propagator for each migration step, we could either instantiate one emigration propagator with the maximum number of emigrants to be sent at once according to the migration topology. However, this again would imply one single selection policy for all islands.
Alternatively, we could pass a list of separate emigration propagators from the user script down to the Pollinator.
Currently, emigration and immigration propagators are passed down to the actual propagator and pollinator using the class itself and not an actual instance. The respective propagators are repeatedly instantiated before every new migration step. However, propagators should be instantiated only once (in the
__init__
).This is also related to issue #61.
The text was updated successfully, but these errors were encountered: