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
I've noticed that the original implementation of PILCO adds an extra variance, equal to the noise of the underlying GPs, in the controller's input. This is done in this line.
I don't see how this is necessary. I guess the original authors found it helpful empirically, maybe for numerical stability etc. Since there might be other design choices like this one, that look arbitrary, I think could do either of two things:
Keep them in our code too, to be consistent with the original application, and assuming that these were found to be beneficial to the algorithm's performance
Not add them if we don't see the benefit, but keep track of them somehow, so in the case we end up having numerical or other issues on a future scenario, we can try adding things from the list.
I think 2 is reasonable, in a sense we are already doing it by not adding any trigonometric augmentation of dimensions that are angles for example, and it keeps our code cleaner until it's necessary to complicate things further.
I've noticed that the original implementation of PILCO adds an extra variance, equal to the noise of the underlying GPs, in the controller's input. This is done in this line.
Currently, we don't do this, so I disabled the relevant line for the unit tests to pass.
@kyr-pol what do you think. Should we add in our code?
The text was updated successfully, but these errors were encountered: