Code: Parameterised types

[Andy Nowacki]

Consider updating your types to be parameterised on the real number type, rather than enforcing Float64. This may enable your code to be used with other number types with other features. For instance, error propagation could be done with Measurements.jl, autodifferentiation done with many libraries, and so on. This would likely require some work to make your code generic everywhere.

[Andy Nowacki]

Just to be clear, I consider this something to consider for the future and for me is not a blocker to the review process.

[Chris Geoga]

Hi Andy, thanks for the note. Looking into this a bit, I think that the more general types would not be able to interface too deeply with this code without a serious overhaul. Most importantly, it looks like FFTW.fft requires BLAS-floats, so the most we could really generalize for the vast majority of our functions would be to include Float32. This also precludes AD for the time being, which would further be inhibited by the fact that the linear algebra routines that get internally used---like dstein and dstebz, for example---are sufficiently obscure that they don’t seem to have generic fallbacks the way that something like LinearAlgebra.LU does, so something like the derivative of an SDF point estimate with respect to a bandwidth parameter or something wouldn’t work currently.

It definitely is interesting, though, and we’ll keep this in mind as we continue to develop and refine the existing methods. Error propagation seems particularly interesting.