Comments (6)
My own rebuttal: Passing invalid values (NaN or non-matching F and Gradient) to Linesearcher is inevitable. We have to pass them either to Finished() or Iterate() (or both as it is now) and Linesearcher decides if it has finished or not and both our Linesearchers decide correctly. So sorry for the noise.
What made me confused is that we pass the same values twice to Linesearcher and I realized that it is not necessary. If we want to minimize the API surface, then we can remove Finished() and instead Iterate() can return e.g. MajorIteration to indicate end of linesearch. I think it would be much cleaner and in line with LinesearchMethod. @btracey ?
from optimize.
With respect to whether Methods can rely on the passed Location to keep its contents between individual calls to Iterate(), I think there are basically two options.
-
We can document that it is implementation specific because it really depends on the combination of the Method and the driver function. Methods would like to reuse the location because it is convenient and saves a lot of copying and this will be the case in 99.9% of cases. However, they have no control over the driver that calls Iterate(). So we can say that Local() (or any other future driver function in the package) does not modify the location apart from requested evaluation (this means we would have to stop invalidating) so Methods can safely build up the location for MajorIteration without having to keep its own copy (they can if they have to). Our methods could rely on that assumtion. If an outsider implements its own driver function, she must not modify the location either, otherwise our Methods would break (and in that case, there is no point in using this package anyway).
-
Say that Methods should make no assumption on the contents of Location not evaluated by the previous request. Methods would always work, but it is not as convenient and leads to a lot of copying.
With respect to Linesearcher.Finished(), I think that replacing it with MajorIteration returned from Linesearcher.Iterate() is the cleanest approach.
from optimize.
I like the MajorIteration return from Linsearcher.
If an outsider implements its own driver function, she must not modify the location either, otherwise our Methods would break
You mean except for the X location?
from optimize.
I like the MajorIteration return from Linsearcher.
Ok, I will submit a PR later when the other one in queue is dealt with.
If an outsider implements its own driver function, she must not modify the location either, otherwise our Methods would break
You mean except for the X location?
I mean that if our Methods relied on the contents of Location not to be modified between calls to Iterate() apart from requested evaluations, then they would break if such modification took place (e.g., we would have to stop invalidating as we do now).
Someone taking our methods and using them in a custom version of Local() outside of optimize is unlikely, but can happen. Someone using its method in our Local() is on the other hand very likely, and in that case knowing that Location is not modified can be convenient for them. So we should decide, remove or keep invalidation, and document the behavior.
from optimize.
Yea, I think it makes the most sense if we promise not to modify. The previous model was "You tell us an X and and Operation, and we'll give that back to you". Now the model is "You fill in Location.X and tell us how to fill the rest".
Someone can't really use our methods outside of Local, as they are unexported. If they create an alternate implementation of Local to use with methods that's fine, but it's on them to keep the same contract.
Lastly, I don't think there's any real harm in promising to not modify location. Local doesn't communicate to the optimizers at present, so it doesn't need to modify the struct. Worst case the data can be copied if it needs to retain the information somehow.
from optimize.
Yea, I think it makes the most sense if we promise not to modify.
Ok. I put some comments in #123 to point out the affected code. I will keep that PR as it is (LinesearchMethod keeps its copy of Location) and will submit this change later in another PR.
Someone can't really use our methods outside of Local, as they are unexported
I don't understand, unexported? Our Methods are exported and can be used outside of the package.
If they create an alternate implementation of Local to use with methods that's fine, but it's on them to keep the same contract.
Ok.
Lastly, I don't think there's any real harm in promising to not modify location. Local doesn't communicate to the optimizers at present, so it doesn't need to modify the struct. Worst case the data can be copied if it needs to retain the information somehow.
Local does not communicate to the optimizers, but we do invalidate non-evaluated fields of Location as a kind of safety measure. That would have to go away.
from optimize.
Related Issues (20)
- Change from Function et al. interfaces + magic to input functions struct HOT 5
- Clearly define meaning of the various iteration types HOT 5
- Make optimize silent by default
- Method does not need ProblemInfo HOT 1
- Better name for ErrNonNegativeStepDirection
- Linesearchers should check function value before asking for gradient HOT 8
- Linesearchers should test function decrease to within a tolerance HOT 2
- Pass a copy of X to evaluation routines HOT 2
- Change the order of arguments for evaluation routines like Grad() and Hess()
- Remove Linesearcher.Finished()
- Change FunConst and GradConst to DecreaseFactor and CurvatureFactor
- [question] MajorIterations settings HOT 4
- optimize: curve-fitting - implement Levenberg-Marquardt algorithm (damped least-squares) HOT 7
- optimize: Add CMA-ES optimization algorithm HOT 3
- optimize: Repo description should not end with a "." HOT 4
- optimize: NewPrinter should accept an io.Writer HOT 1
- optimize: allow constrained optimization HOT 6
- Update of OptLoc on every iteration causes flaky optimization runs HOT 11
- Statuser docs are not accurate
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from optimize.