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
{{ message }}
This repository has been archived by the owner on Nov 23, 2018. It is now read-only.
I have been giving it more thought and I am still not convinced that passing ProblemInfo to Method.Init() makes sense. Methods already announce what they need via Needs() and we allocate fields of Location exactly according to this information. Evaluation types issued by Method should/have to match this information. So ProblemInfo will convey what Needs() returned plus perhaps something more but Method cannot use that information anyway, it cannot issue evaluation types beyond Needs(). Comments, @btracey ?
The text was updated successfully, but these errors were encountered:
My thought on having it was that hypothetically Methods could have different behavior depending on the ProblemInfo. I'm not sure I have a good example though. The one I had in mind was random restart global optimization. In this case though, the Restarter struct would have something like
type Restarter struct{
Local Method // The local optimization method for each restart
}
Here though, Restarter.Needs() would just return Local.Needs(), and so it doesn't need ProblemInfo.
I have been giving it more thought and I am still not convinced that passing
ProblemInfo
toMethod.Init()
makes sense. Methods already announce what they need viaNeeds()
and we allocate fields ofLocation
exactly according to this information. Evaluation types issued by Method should/have to match this information. So ProblemInfo will convey what Needs() returned plus perhaps something more but Method cannot use that information anyway, it cannot issue evaluation types beyond Needs(). Comments, @btracey ?The text was updated successfully, but these errors were encountered: