Skip to content
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

[BUG] - Fix description of time constant estimation #302

Merged
merged 2 commits into from
Sep 13, 2023
Merged

Conversation

TomDonoghue
Copy link
Member

@TomDonoghue TomDonoghue commented Sep 12, 2023

We have a function the repo to estimate 'timescales', added in here. I happened to notice that the function we have here described the calculation as being estimated from the knee parameter, whereas Richard's work estimates it from the knee frequency - which I assume is correct? If so, this is currently incorrectly described here, and this PR updates that.

This is what I'm following from Richard's work:
https://github.com/rdgao/field-echos/blob/master/echo_utils.py#L65

I know the "knee frequency" calculation is an estimation - this function should at least be updated to describe the correct parameter - should we also add a bit of note describing it more and/or referencing this to Richards paper? Thoughts, @rdgao?

@TomDonoghue TomDonoghue added the 1.1 Targetted for a fooof 1.1 release. label Sep 12, 2023
@rdgao
Copy link
Contributor

rdgao commented Sep 12, 2023

yes that's exactly right - I noticed this at some point myself and forgot to do anything about it.

but yeah, in the function/equation in question it should be the knee_frequency, and that doesn't involve estimation, it just converts frequency to time and that's always right.

What might be a good thing to point out is in the function above (compute_knee_frequency, L8), that that involves a non-exact approximation depending on exponent. I didn't find any references that do this for the "general" Lorentzian case when I was working on it, so I'm still not sure if it's right. But maybe make this reference so people know who to blame.

@TomDonoghue
Copy link
Member Author

@rdgao - sounds good, thanks for the info!

I added a new commit that adds explicit references to your paper, and also adds a note on the conversions, describing what you mentioned about it being an estimate rather than a precise quantity - do you want to take a quick look and double check it captures what you want it to?

@rdgao
Copy link
Contributor

rdgao commented Sep 13, 2023

yeah looks good to me!

@TomDonoghue TomDonoghue merged commit a022997 into main Sep 13, 2023
@TomDonoghue TomDonoghue deleted the kneetime branch September 13, 2023 12:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1.1 Targetted for a fooof 1.1 release.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants