On Mon, 21 Jul 2014 02:16:46 -0400, Leza Morais Lutonda
Yes, it works as expected, e.g, now I have instances of FourierTrasformable for List [Double] and for HMatrix.Vector Double, and the following works well:
fft (toComplex [1,2,3,4 :: Double]) [10.0 :+ 0.0,(-2.0) :+ 2.0,(-2.0) :+ 0.0,(-2.0) :+ (-2.0)] fft (toComplex $ vector [1,2,3,4]) fromList [10.0 :+ 0.0,(-2.0) :+ 2.0,(-2.0) :+ 0.0,(-2.0) :+ (-2.0)]
I think (if I understand well) this is because the constraints (RealSignalType (ComplexSignalType s) ~ s) in the Complexable class definition and (csx ~ ComplexSignalType s, ComplexSignal csx) in the fft definition makes a one-by-one dependency between s and csx.
I think you may be right. I missed the changes to the ComplexSignal class in between this and your original edit, I was just fixated on the fact that your new ‘fft’ definition looked nearly identical to your first. You can drop the forall csx. bit, for what it's worth, since csx is an unbound variable either way (and hence implicitly quantified).