Hi
There are quite a few reasons why it is implemented the way it is:
We actually don't provide the Complex type ourselves but use the one provided in the .NET Framework in System.Numerics. We only reimplement it for (and only for) our portable builds because System.Numerics is not available in some environments like Windows Phone. We do provide Complex32 because no such type is provided by the framework, but align its members with the Framework's Complex type for obvious reasons.
Then, other than C++ templates, C#/IL generics don't work well with generic arithmetic (because they're not "inlined"/resolved at compile/linker time) and all workarounds I'm aware of (in C#, F# is much better here with its inline keyword) are either very complicated or very inefficient. So we'd end up having to implement concrete implementations anyway like we do in linear algebra. Note that these types are structs, not classes, so they can't inherit from some common generic base class. They could implement a generic interface, but we cannot modify the Complex type from System.Numerics so this won't work either.
There's also a problem with the algebraic structure: byte, int, long etc. are integer types and thus do not form an algebraic field (e.g. they lack a multiplicative inverse). Indeed, integer and fixed-point arithmetics is very different from floating point arithmetics and needs a lot of extra care to make sure every intermediate value is well conditioned. Also a lot of basic routines are only provided for floating point types in the framework.
Interestingly it seems even FFTW, likely the most robust and fast FFT implementation by far, only supports floating point types.
All that being said, it's certainly possible to implement fixed-point and integer FFT. For example, see this paper. I actually think it would be interesting to support integer FFT in Math.NET, although it may better fit to our signal processing library as opposed to Numerics, as integer samples are quite common in signal processing.
In the meantime, would it be reasonable in your situation to simply convert your samples to floats to perform the transform? Or would you be able to help us implement proper integer FFT?
Thanks,
Christoph
There are quite a few reasons why it is implemented the way it is:
We actually don't provide the Complex type ourselves but use the one provided in the .NET Framework in System.Numerics. We only reimplement it for (and only for) our portable builds because System.Numerics is not available in some environments like Windows Phone. We do provide Complex32 because no such type is provided by the framework, but align its members with the Framework's Complex type for obvious reasons.
Then, other than C++ templates, C#/IL generics don't work well with generic arithmetic (because they're not "inlined"/resolved at compile/linker time) and all workarounds I'm aware of (in C#, F# is much better here with its inline keyword) are either very complicated or very inefficient. So we'd end up having to implement concrete implementations anyway like we do in linear algebra. Note that these types are structs, not classes, so they can't inherit from some common generic base class. They could implement a generic interface, but we cannot modify the Complex type from System.Numerics so this won't work either.
There's also a problem with the algebraic structure: byte, int, long etc. are integer types and thus do not form an algebraic field (e.g. they lack a multiplicative inverse). Indeed, integer and fixed-point arithmetics is very different from floating point arithmetics and needs a lot of extra care to make sure every intermediate value is well conditioned. Also a lot of basic routines are only provided for floating point types in the framework.
Interestingly it seems even FFTW, likely the most robust and fast FFT implementation by far, only supports floating point types.
All that being said, it's certainly possible to implement fixed-point and integer FFT. For example, see this paper. I actually think it would be interesting to support integer FFT in Math.NET, although it may better fit to our signal processing library as opposed to Numerics, as integer samples are quite common in signal processing.
In the meantime, would it be reasonable in your situation to simply convert your samples to floats to perform the transform? Or would you be able to help us implement proper integer FFT?
Thanks,
Christoph