Function dft_accelerated 

pub fn dft_accelerated(x: &[Cplx]) -> Vec<Cplx> 

Best-path forward DFT for spectral callers that accept f32 precision: X[k] = Σ_n x[n] · e^{−2πi kn/N}, same un-normalized forward convention as dft, but accelerated on the GPU when possible.

Why this is a separate function (and dft is not silently swapped)

The forge FFT is f32 (WGSL has no f64), so an accelerated result carries f32 precision (≈ 1e-3 .. 1e-2 of the spectral magnitude for N ≤ 1024), not f64-exact bits. Routing the public dft through it would break callers that rely on its f64-exact contract (e.g. the idft round-trip). So the fast path is exposed here as an explicit opt-in: callers doing audio / magnitude / feature-extraction style work — where f32 is the universal norm — choose it knowingly. The inverse idft stays wholly on the CPU (the forge FFT is forward-only).

Convention match (no rescale)

The forge’s radix-2 FFT and its CPU DFT oracle (crate::wgsl_forge::dispatch::fft_f32) use the identical un-normalized forward sign convention e^{−2πi kn/N}. So the forge result is the same transform as dft — no sign flip, no 1/N / 1/√N rescale is applied, only an f64 → f32 → f64 width conversion.

Path selection

The WGSL forge runs only when all of:

• N = x.len() is a power of two and 2 ≤ N ≤ 1024 (the forge runs ONE workgroup of N threads, so N is bounded by the single-workgroup size);
• a wgpu accelerator is present on this machine (caps().wgpu).

Otherwise — and on any forge error — it falls through to the f64 CPU DFT (dft’s exact math). The result is always a valid forward DFT; only the precision (f32 vs f64) and the compute device differ between the two paths.