Yes, would be nice. Even better to support float32 and complex64 in the regular fft calls... Previously, it has been stated one should use scipy for this, but since that stores the transforms in a logical but very inconvenient format (not proper complex numbers), there is a case to be made to extend numpy. In principle, it is just a matter of compiling the same C source twice, with different definitions of DOUBLE -- which affects Treal in https://github.com/numpy/numpy/blob/master/numpy/fft/fftpack.c#L14

I'm not sure that it is even that complicated. Should be a simple matter of changing this line and this line to not force float.

Using np.reciprocal there would work, right?

@eric-wieser
Sorry, I don't understand, what is the relationship between np.reciprocal and the dtype issue here?
And can I make a PR to match the output type with the type of d?

I think this is a little tricker than just changing the line, since there are two times the likely float value gets multiplied with an int, first in val = 1.0 / (n * d), and then again at the very end, results * val. Instead, it is probably best to set the dtype in the creation of results, and then do calculations inplace.

In addition to (or instead of?) the dtype argument, should one add an out argument? To make it most similar to ufuncs, the signature might then become fftfreq(n, d=1.0, out=None, dtype=None) (that said, arange -- which this really is an elaborate version of -- does not have an out argument, but does have dtype).