-
Notifications
You must be signed in to change notification settings - Fork 100
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Knee Parameter #224
Comments
Ooops - my apologies, I apparently missed this issue / question! I think updating the knee from the 'parameter' to the 'frequency' generally makes sense. This is a significant change to what we report, but could be bundled and described into the 2.0 major release, which is a breaking change anyways. I wonder if there is any particular difference / benefit to fitting the knee frequency directly, versus continuing to fit the parameter and then converting post hoc to frequency to update the value we return? We could do either - I'm just not sure if there is any particular reason to prefer one or the other. Also - tagging in knee expert @rdgao for any comments! |
chiming in here: the knee parameter is technically a "well-defined" quantity that just falls out of the "generalized Lorentzian". Like, if you plug that number back into the equation, you get what you want out. knee frequency, on the other hand, is sort of an "interpretation", if you will. It's "roughly where the spectrum falls off from the plateau", but it's a rather vague definition, as opposed to something like "knee frequency is where the power is half max in the Lorentzian (or whatever)". In other words, if you fit In the case exp=2, there is a correspondence, but for any other exponents, it's more like a guideline. I just kinda hacked it and extrapolated from exp=2 to in general take the inverse power. All that being said, I think if you just defined (clearing my inbox and just found this, sorry!) |
actually to be more precise: the correspondence I meant for exp=2 refers to the fact that the PSD of an exponential decay with a time constant of T is:
when the fitted exponent is not 2, you can't go the inverse direction and find |
Thanks for the follow up @Rdago. All of this makes sense. I ran tests and don't think one model is consistently more numerically stable than the other. There's tradeoff in stability depends on combinations of parameters (knee, exp, f_range, oscillations, curve_fit bounds, etc) and the difference in knee and exponent error is on the order of 1e-16. |
Hello,
Would anyone have an implementation/fork of that already? |
Seems I can just include the changes from here in my code? |
Thanks! I got it to work with the code. Can't wait for this to be integrated in a new version. |
@TomDonoghue do you think it would be useful to add an option to fit a knee frequency parameter? I have a fork where I've converted
y = 10^offset * (1/(knee + x^exp))
toy = 10^offset * (1/(knee_freq^exp + x^exp))
. This is based on the knee to knee_freq conversion:knee_freq = knee**(1./exponent)
. I think this makes the knee parameter a more interpretable feature of spectra, and it allows passing bounds like (1, 40 Hz) to curve_fit if one wants to limit the range of knee freq locations.The text was updated successfully, but these errors were encountered: