[Feature Request] Document tuning parameters and relationship between covariance tuning and filter run rate

[impredicative]

When I am calling kalmangrad.grad as below:

smoother_states, filter_times = kalmangrad.grad(y, t=t / HERTZ, delta_t=1 / HERTZ)

I noticed that the value of HERTZ above makes a huge difference in the result of smoother_states. I tried values such as 1, 30, 60, 100, 120, 240, etc. Essentially, it was necessary for me to tune HERTZ for suitability. This is not something I was expecting, but it provides me an opportunity for optimizing the result. If I had left it at 1, the result would have been indistinguishable from noise to me.

Even before this, I had already adjusted t by shifting it to start at 0, and then dividing it by its GCD.

(I don't believe I need anything for this issue. I'm just documenting the usage.)

[hugohadfield]

Hi @impredicative
From my perspective it seems very strange to be dividing your time values by Hertz.. Im curious as to why you are setting up your problem this way? would it be possible to share some code snippets for what you are attempting to do more generally? It would be really helpful as a way of working out what additional documentation I need to write for the package :)

[impredicative]

I started by not dividing, which is effectively using a value of HERTZ=1. Unfortunately, this led to the first derivative which was too close to zero. This output was not useful to me.

By setting higher values of HERTZ, I could get higher absolute values of the derivative, also then not crossing the 0 line too often. The higher the value of HERTZ, the less the derivative crossed the zero line. I found a balanced value. I couldn't have too high a value either as it trades-off noise for lag.

As an aside, what I did is plot (observations, observations+estimated_first_derivative) to visualize the two lines on the same plot.

[hugohadfield]

I'm afraid I don't know what you are referring to by crossing the zero line, seems like quite a problem specific optimisation you are going for here! Either way, dividing both your time and your delta_t like this is effectively similar to changing the final argument of the function which adjusts the highest order derivative diagonal covariance value. If you get rid of your division and instead play with that parameter do you get the same results?
If you provide me with a minimal example of your code I would be happy to help you tune this :)

[impredicative]

crossing the zero line

By this I just mean a change of sign of the estimated first derivative from negative to positive or vice versa.

[hugohadfield]

Ok cool, what I will do for now then is rename this issue to:
[Feature Request] Document tuning parameters and relationship between tuning and filter run rate
To remind me to add a load of information about how people can tune their filters and what to do if it doesn't work. I'm glad your are opening these issues, its good to know how to improve the library and that people are actually using it for their projects!

[impredicative]

OK. I intend to tune the last covariance parameter and update.

[hugohadfield]

Awesome, thanks @impredicative , excited to hear if it works for your use case 🤞

[impredicative]

Both HERTZ and final_cov affect the derivative differently for me.

With regard to the derivative, HERTZ affects the rate of sign changes and the magnitude of the derivative. Higher value of HERTZ looks to produce more frequent sign changes and a smaller magnitude of the derivative. Lower values of HERTZ look to produce less frequent sign changes and a much greater magnitude of the derivative. A value of 60 looks to work well for me for my use case, although I need to optimize it using more realistic reward criteria to be sure.

I am not strongly a math person, and unfortunately I don't really have an intuition or a sense for what final_cov is supposed to mean or how to analytically set it. GPT however provided me some guidance (mirror) in this regard. I tried optimizing it on the log scale, only to find that its default value of 1e-4 is just fine for me. Values of say 1e-2 or 1e-6 are worse for me. Lower log-scale values of final_cov look to produce more frequent sign changes of the derivative. Higher log-scale values look to produce less frequent sign changes, but greatly deteriorate the resulting signal. Without further information, I think I'll stick with its default value for now.

In summary, HERTZ and final_cov probably are not substitutes for each other for my current use. Further updates to my settings can be done after a better optimization search. Thus far I have been setting them visually by plotting the outcomes.

Personally I do not really need any documentation update at this time in this regard, but I'll leave it to you.

[hugohadfield]

Thanks so much for these investigations @impredicative . I'm glad you have settled on some values that work for your application. I'll leave the issue open as a reminder to me to write a guide/some helper functions for tuning :) I hope kalmangrad continues to be useful for you and let me know if you have any feature requests/bugfixes!