Comments (7)
I don't know exactly what was the reason for that any more. Would be interesting to find out if the numerical solution is more stable or slower though. It shouldn't be too difficult to change the implementation to use the analytical solution. If you have any insight, please let us know. I will leave this issue open for now.
from bolero.
I'll change the implementation and see how it affects performance and stability. When I have some insights I'll get back to you.
from bolero.
Hey @AlexanderFabisch,
I have done some tests comparing the performance of using the numerical vs analytical computation of the gradient of the dual function, and it seems that:
- For REPS computing the analytical solution may lead to slightly increased computational overhead but may also lead to better solutions (found minimizing the Rosenbrock function). Perhaps for more complex optimization problems the overhead of computing the gradient is not as significant so overall computational time is reduced?
- For C-REPS computing the analytical solution may lead to much faster optimization (check this) but I found no evident of it leading to better (or worse) solutions.
Regarding stability I have had no problems during my testing. For all the exponentials I've subtracted the maximum value so the implementation should be relatively safe.
A clean implementation without any of the testing functions can be found here. Feel free to validate my results and tell me if you want me to pull request.
from bolero.
For REPS computing the analytical solution may lead to slightly increased computational overhead but may also lead to better solutions (found minimizing the Rosenbrock function). Perhaps for more complex optimization problems the overhead of computing the gradient is not as significant so overall computational time is reduced?
That seems to be surprising to me. I would expect that it is faster because the optimizer will otherwise call the objective function multiple times to estimate the gradient. Also can't reproduce this:
$ python reps_rosen_time.py
...
Numerical gradient completed in average time of 2.03754606247 seconds
...
Analytical gradient completed in average time of 1.91270718575 seconds
For C-REPS computing the analytical solution may lead to much faster optimization (check this) but I found no evident of it leading to better (or worse) solutions.
Looks great.
Regarding stability I have had no problems during my testing. For all the exponentials I've subtracted the maximum value so the implementation should be relatively safe.
Maybe @jmetzen remembers why we didn't implement the analytical solution?
A clean implementation without any of the testing functions can be found here. Feel free to validate my results and tell me if you want me to pull request.
A pull request would be awesome. Maybe we can also put some test scripts to the benchmark folder.
from bolero.
That seems to be surprising to me. I would expect that it is faster because the optimizer will otherwise call the objective function multiple times to estimate the gradient. Also can't reproduce this:
That is also what I expected so I am a bit puzzled by why that is sometimes not the case.
Maybe we can also put some test scripts to the benchmark folder.
Do you mean benchmarks for numerical vs analytical or for REPS / C-REPS in general?
from bolero.
Maybe we can also put some test scripts to the benchmark folder.
Do you mean benchmarks for numerical vs analytical or for REPS / C-REPS in general?
You can add those scripts that you implemented to compare the numerical and analytical gradient so that they are not lost.
from bolero.
We use the analytical version of both gradients in the master now.
from bolero.
Related Issues (20)
- Stale branch
- _ranking_svm.c is missing HOT 2
- Build errors with Debian / Python 3.7 HOT 9
- ValueError: numpy.ufunc size changed, may indicate binary incompatibility. HOT 2
- Before init, optimizers cannot be pickled
- Examples only with matplotlib version <3.1.0 compatible
- Install bolero on Fedora Workstation HOT 2
- Broken link HOT 2
- Check if cython runs successfully
- can't find cart_dmp_config.yaml and cart_dmp_model.yaml in the example python scripts HOT 2
- Optimizer interface changed HOT 5
- ModuleNotFoundError: No module named 'dmp' HOT 1
- ProMP Heisenbug HOT 8
- Python 3 compatibility HOT 1
- Reloading DMPs produces wrong trajectories after re-execution HOT 2
- Check if documentation builds with Python 3
- Not all spaces can be handled by OpenAI Gym wrapper
- Suggestion for new logo? HOT 1
- Python 3 bugs
- CppBLLoader cannot be imported HOT 4
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 bolero.