Ufuncs and Reductions

A Python for loop over a million-element array is slow because each iteration pays the overhead of the Python interpreter itself. A ufunc (universal function), like np.add, np.exp, or np.sqrt, instead applies an operation to every element of an array using pre-compiled C loops, so the interpreter overhead is paid once per array call, not once per element. This is why np.exp(returns) on a million-row array runs orders of magnitude faster than [math.exp(r) for r in returns].

A reduction is the second half of the pattern: it collapses an array along one axis using a ufunc's underlying binary operation, arr.sum() reduces by repeated addition, arr.max() by repeated comparison, arr.prod() by repeated multiplication. Every ufunc that takes two arguments (like np.add) automatically has a .reduce() method, so np.add.reduce(arr) is literally what arr.sum() calls under the hood.

Worked example: given daily returns for 500 stocks over 252 days, stored as a $(252, 500)$ array, daily_returns.sum(axis=0) reduces along the time axis (axis 0) to produce a single 500-length array of total returns per stock, one number per column, computed without a single explicit Python loop. Compare axis=0 (collapse rows, keep columns, one result per stock) against axis=1 (collapse columns, keep rows, one result per day); mixing these up is the single most common source of silently-wrong cross-sectional statistics in a research pipeline.