`runmean` doesn't support `Int` array
Moelf opened this issue · 7 comments
It's reasonable to get the running avg of new cases per day (an example). I can make a PR if this makes sense
Hey @Moelf, thanks for making this request. It shouldn't be too hard to increase the coverage of numeric types.
The only downside I would suspect would be an increase in the amount of pre-compilation time, as the JIT compiler will need to compile the code for more types. (Instead of optimizing only for float types, it would need to work through the integer type tree as well.)
But I will do some experimenting on if there is a noticeable performance hit that comes from expanding the type coverage, and if not, I'll get some code pushed and work it into the next release.
well, I think it's natural to run sma on a Araay{Int,1} so either make runmean support it or implement a different thing for sma
I agree, it's a common enough use case that the code should be general enough to handle it.
I realized that the type signatures between run.jl and ma.jl differ, so it's also best to keep things internally consistent.
One problem I just realized that will require some deeper fundamental changes to the code is the pervasive use of NaNs, which is a float type and doesn't play well with int types. So I'm going to need to figure out how to get Julia's relatively young missing feature set to work in here in place of the NaN fill value. So this might take a little more time than I anticipated.
oh, eh, don't worry, I think people expect to get back a float array if they run sma on even an integer array
@Moelf I took your idea to just make the output arrays consistent with float element types, but be able to take any input types under the real numbers. Take a look at commit f943b94 and let me know if takes care of things for you. It's on master so you should be able to just checkout and pull the latest to give it a test run.
I'm going to close this issue for now. Let me know if you are still having problems and I can reopen.