Replies: 1 comment
-
Hm interesting idea and I think you are right that specifying L_frac as a fraction of the total time interval would give it more physical meaning. I'm not sure I fully see how to derive the point fraction from the time fraction using the mean time separation - in particular - would this be meaningful for the case we want to cover (non-uniformely distributed cloud hits)? On the one hand, the mean would probably be quite affected by the distance between point clusters. Maybe this would still be ok as the overall integration time is anyways quite limited. On the other hand, using the median would likely be too affected by the time distances in the largest point cluster. So in short - I like the idea but I think I need a whiteboard session to either fully get the idea or to refine it. |
Beta Was this translation helpful? Give feedback.
-
At the moment, the parameter L_frac for the LOWESS fit is defined exactly as it needs to be fed to the underlying statsmodel routine, i.e. it represent a fraction of points that are used to derive the local fit at a given position.
This has some drawback for low density layers, that will be overfitted (because 0.35 % of e.g. 5 points implies that each point will be fitted).
One idea could be to specify L_frac as a fraction of the total time interval. This would make more sense from a physics perspective, because the user would know exactly the timescale of variations that will get fully seen by the LOWESS fit. It would help the case of low density layers with 5 hits close from one another, but it would NOT change anything if the 5 hits are located far apart (i.e. as in a very fast and very sparse cloud layer ?).
The catch would then be to convert a time fraction to a points fraction in the fluffiness routine, which is not immediate given that points may not be uniformly distributed. One option would be to compute the mean time separation between each hit, and then derive L_frac from this. Clearly, this would need some tests.
Nonetheless, I think this could possibly be an interesting feature to improve the "physical understandability" of the code parameters.
@regDaniel and @loforest: I'm leaving this here for now. Feel free to close it anytime, if you do not think this is worthy.
Beta Was this translation helpful? Give feedback.
All reactions