What's the reason for the `m` value?
scooter-dangle opened this issue · comments
https://github.com/bhatiasiddharth/MIDAS/blob/c1e4e6b316d007165907db44efcefab9fd8b02f8/anom.cpp#L50
Since we have no guarantee that the first and last values of the inputs are different (or, if they are different, that they differ by any particular magnitude), why not just supply m as an input to the program?
(I looked through the paper. Apologies if I missed an explanation there.)
max_element returns the iterator to the greatest element in the range [first, last) rather than maximum of first and last.
Ah, thanks for pointing that out—I'm not familiar with the C++ std lib.
So it's really just the max value of the domain. Is there any particular reason for that? Like, would it negatively affect the output to set it to just, say, 773 (the next prime after 769)?
Be tea dubs, I wrote a Rust version and Python bindings to it.
Additional questions:
- I've listed the license for the Rust version and Python bindings as Apache 2.0. Would you be okay with it being dual-licensed under MIT (per https://rust-lang.github.io/api-guidelines/necessities.html#crate-and-its-dependencies-have-a-permissive-license-c-permissive)?
- When the current time increases, what's the reason for not lowering by
factornew_time - current_time? E.g., if we're atcurrent_time = 5and the next entry hastime = 7, wouldn't we want to essentially runlowertwice to properly apply decay?
- Changing value of
mto a reasonable value should be fine. It does not necessarily need to be the maximum. - Nice idea and extension to lower by
factornew_time - current_time.
Thanks, for the Rust version and Python bindings. They look nice! I have added links in the README.
Also, I am fine with them being dual-licensed under MIT.
I have added links in the README.
Also, I am fine with them being dual-licensed under MIT.
Thanks so much!