Discrete Fourier Transform Calculator

What does this discrete fourier transform calculator compute?

The unnormalized DFT is X[k]=Σ_n x[n] e^{−2πi kn/N}. The inverse (Numpy backward) is x[n]=(1/N) Σ_k X[k] e^{2πi kn/N}. Direct O(N²) for any N≤64; radix-2 Cooley–Tukey when N=2^k.

The published formula or method is X[k]=Σ x[n] e^{−2πi kn/N}; x[n]=(1/N) Σ X[k] e^{2πi kn/N}. The following references support the stated mathematics or method:

• NumPy — Discrete Fourier Transform: DFT and inverse-DFT definitions, frequency ordering, and backward normalization; does not establish this implementation’s accuracy.

Which inputs and limits should you check?

Retain the full complex sequence and distinguish the unnormalized forward transform from the 1/N inverse normalization. FFT presets also impose the stated sequence-length restrictions.

The worked example uses samples = 1,0,0,0 with X = [1, 1, 1, 1]. Compare it with the Example calculations and the complete result for the same inputs.

How can you verify and cite this result?

CalculatorX is responsible for this page. The mathematical references above explain the model; implementation checks and their scope are documented separately in the math.transform.dft v1.2.3 Evidence and capability contract. Read the displayed verification and production state together with the specification's numerical limits.

Use the clean calculator URL to cite the tool. A shared input link identifies a particular calculation. Content updates, numerical verification, and domain reviews have separate dates and scopes.

Numerical precision and input policy

Use 1–64 finite binary64 samples; FFT/IFFT require a power-of-two length. Decimal scalar, CSV/JSON sequence, real array, [re, im] pairs, and objects with re/im are supported. Optional im must have the same length. Supplied samples/x/re, mode/method, and embedded/separate imaginary components must agree; malformed lists, empty required values and unknown fields are rejected. Locked entry presets choose their displayed mode.

Forward transforms are unnormalized; inverse transforms divide by N. Exact dyadic sums and products of binary64 samples and binary64 twiddle approximations avoid intermediate overflow and preserve cancellation in these operations. Cardinal roots of unity are exact. Other trigonometric factors remain approximate: this is a floating-point transform, not an exact symbolic transform. Input echoes preserve binary64 precision; output components and magnitudes publish 12 significant digits.

The independent listed-fixture comparison uses component relative 1e-8 plus spectrum-peak absolute 1e-12, allowing four smallest subnormal ulps. This is a verification budget, not a per-input error bound. Relative accuracy can weaken near zero bins or cancellation, even though the transform has good normwise conditioning. Nonzero decimal input that converts to zero returns NUMERIC_UNDERFLOW. A nonzero evaluated output component that rounds to zero, or a nonfinite output/magnitude, returns NUMERICAL_RANGE_ERROR; roundoff near a mathematical zero can also trigger this refusal at extreme scales.

The stem plot shows magnitudes by discrete bin/sample index, with index 0 highlighted. It is not a physical-frequency spectrum or phase plot. Bins too small relative to the peak can be visually indistinguishable from zero; the complete numeric sequence and exports retain their published values.

Ordinary calculations run locally. A shared URL sends inputs to the server and may appear in server logs; browser history may store results on this device. REST/MCP requests send inputs to the service. No zero-log, retention-period or processing-region guarantee is implied. Shared version labels identify the requested calculation; they do not provide an archived browser engine.