The simplest professional response to "don't send one giant market order" is TWAP (Time-Weighted Average Price) scheduling: split the total order into equal-sized slices, one per time bucket, and send each bucket's slice as its own smaller order (code-pack Exercise 3, twap_summary). "Equal-sized" needs one piece of exactness that is easy to wave away and shouldn't be: if total_qty doesn't divide evenly by the number of buckets, the leftover shares have to go somewhere, and this module's convention (matching real scheduling code, which must always account for every single share) is to give the remainder to the first buckets, one extra share each, so the schedule always sums to exactly total_qty: 101 shares over 5 buckets becomes [21, 20, 20, 20, 20], never a fractional share anywhere. TWAP's benchmark, the number you grade your execution against, is the plain, unweighted mean of the market's own price sampled once per bucket. This is worth sitting with: the benchmark is unweighted by design, because "time-weighted" means every unit of time counts equally regardless of how much volume traded in it, which is exactly TWAP's blind spot, taken up in Common Mistake #3 and in the VWAP section next.
Advertisement
VWAP: sizing slices to the market's own rhythm
Real trading volume is never flat across a session, it is famously heaviest at the open and the close and thinner through the middle of the day (a "U-shape" or "smile"), because that's when the most participants are actively trading and, historically, that's when the deepest liquidity shows up. VWAP (Volume-Weighted Average Price) scheduling responds to this directly: instead of slicing evenly across time, size each bucket's slice proportionally to that bucket's share of a volume profile (historical or predicted), so your own footprint mirrors the market's natural rhythm rather than fighting it (code-pack Exercise 4, vwap_summary). The proportional math introduces the same "where do the leftover shares go" problem as TWAP, but now the exact proportions are almost never whole numbers, so this module uses the standard largest-remainder apportionment method (the same family of algorithm used for allocating parliamentary seats, this is a genuinely general "how do you round several numbers so they sum to an exact integer target" tool, not a finance-specific trick): compute each bucket's exact proportional share, take the floor of each as a starting allocation, and hand out the leftover units one at a time to the buckets with the largest fractional remainder, ties broken by giving it to the earlier (lower-index) bucket. VWAP's benchmark is the true volume-weighted mean, sum(price × volume) / sum(volume), and here is the payoff that makes VWAP scheduling popular: because your own schedule is built to mirror the volume profile that defines the benchmark, a VWAP scheduler's realized execution price naturally lands extremely close to the VWAP benchmark, with only a small residual from the integer rounding the apportionment method has to do. Worked Example 4 makes this concrete with real numbers; Practice Problem 6 shows the case where the rounding happens to come out perfectly even, and the residual slippage is exactly zero.