Expected Value and Hourly Rates: A Measurement-Boundary Guide

1. Expected value is a weighted average

For a discrete outcome table, expected value is the sum of each possible value multiplied by its probability. Penn State's mathematical expectation lessongives the formal definition:

gross EV per attempt = Σ(valueᵢ × probabilityᵢ)

The table must use one version and one valuation unit, and its probabilities must describe the full outcome space.

2. Gross EV, net EV, and observed net are different

net EV per attempt = gross EV - expected direct cost
observed batch net = observed gross value - observed direct costs

The first line needs a probability distribution. The second line is deterministic accounting for one recorded batch and does not estimate an undisclosed drop rate. Both can be useful, but they answer different questions and should not share the same label.

Hypothetical EV example

Assume an invented, mutually exclusive table with values 0, 4, and 20 units at probabilities 60%, 30%, and 10%. Gross EV is 3.2 units. With a 0.7-unit direct cost per attempt, net EV is 2.5 units. The example demonstrates the arithmetic only; it is not a rate or price for a game.

Observed batch example

Suppose a 12-map batch records 180 units of gross return and 65 units of direct costs. Observed net is 115 units, or about 9.58 units per map. That describes this batch. It is not automatically the long-run EV of future maps.

3. Define the complete cycle before dividing by time

For a repeatable expected-value model:

cycles per hour = 3600 / complete cycle seconds
expected net per hour = net EV per cycle × cycles per hour

For a recorded batch:

observed net per hour = observed batch net / (complete batch minutes / 60)

A complete boundary may include:

• acquisition and preparation;
• travel, queue, loading, and setup;
• the action itself, failures, deaths, and recovery;
• looting, inventory, stash, reset, and return travel; and
• valuation or selling time when the result claims realized market throughput.

Two routes cannot be compared fairly if one clock starts at the target and the other starts in town. A faster number created by omitting inconvenient stages is a boundary mismatch, not an efficiency finding.

4. Prices and value units need provenance

Record at least:

• the value unit and platform, region, league, server, or realm where relevant;
• the observation source and timestamp;
• stack size, fees, liquidity, and whether a price is a listing or completed transaction;
• the same valuation convention for rewards and costs.

LootCalc does not maintain a universal live market feed. Current retained profit tools either ask for user-entered values or accept an already-valued batch total. An old static price should not be relabeled as current because the formula around it is still valid.

5. Variance belongs beside EV

Two outcome tables can have the same EV and very different distributions. A rare large outcome may dominate one table, while another produces smaller values more often. EV alone does not state the chance of a loss, the length of a dry period, or the working balance needed for repeated costs.

If the full distribution is known, report percentiles or loss probability alongside EV. If only batch totals are known, show the individual batches and avoid presenting one favorable batch as a probability model. The binomial sampling guideexplains why selected samples cannot validate a hidden rate.

6. Common invalid comparisons

• Incomplete distribution: a rare outcome is included but common costs or failures are missing.
• Mixed clocks: travel or selling appears on only one side.
• Mixed units: account progress and trade currency are added without a stated conversion.
• Historical price drift: values come from different dates or versions.
• Listing-to-sale leap: an asking price is treated as realized value.
• Selection bias: the best route or batch is chosen after inspecting outcomes.
• EV-as-guarantee: a long-run average is presented as the result of one attempt.

7. Reproducible worksheet

scenario_id, version, value_unit, valuation_source, valued_at,
attempts_or_units, observed_gross, direct_costs,
timer_start, timer_stop, complete_minutes, exclusions

If you have a full sourced outcome distribution, add one row per mutually exclusive outcome with its probability and value. Otherwise keep the record as batch accounting; do not manufacture a distribution from the aggregate.

8. Current LootCalc examples

• Path of Exile Map Batch Profit Calculator — observed/what-if gross and direct-cost totals over one complete batch.
• Diablo 4 Helltide Resource Plan — deterministic resource accounting with user-defined value units, not a hidden reward table.
• Borderlands 3 Drop Scenario — user-entered target and conditional probabilities with complete-cycle timing.

Sources and related reading

• Penn State STAT 414: Mathematical Expectation
• Drop-rate mathematics and probability model boundaries
• LootCalc evidence and input policy