One instrument in a 3000 name portfolio has a missing mark stored as NaN. The total risk report shows NaN for the whole book, and a filter written as value greater than a threshold silently drops that name instead of flagging it. Explain both behaviours and give the handling you would build.

One instrument in a 3000 name portfolio has a missing mark stored as NaN. The total risk report shows NaN for the whole book, and a filter written as value greater than a threshold silently drops that name instead of flagging it. Explain both behaviours and give the handling you would build.

Approach: Follow the IEEE rules for arithmetic with a NaN operand and then for comparison with one, and note that the two rules have opposite consequences downstream.

Any arithmetic involving NaN produces NaN, so one missing mark poisons every sum it enters and the book total becomes NaN, while under the IEEE comparison rules every ordered comparison with NaN is false, so a greater-than filter silently excludes the name and even an equality test against itself is false; build explicit handling that counts and reports missing values before any aggregation runs. The NaN propagation through addition is the useful half, since it makes the corruption visible in the total. The comparison behaviour is the dangerous half, because filters, sorts and min or max reductions change meaning quietly, and a comparator that returns false in both directions violates the strict weak ordering a sort requires, which can read out of bounds. Detect with an is-nan test rather than an equality test, count the failures per book, and fail the report listing the affected names instead of publishing a number that hides them.

Follow-up: What does a NaN do to a running maximum written with a simple if, and how does that differ from the standard library max?

Key concepts: nan propagation, ieee comparison rules, strict weak ordering, missing values.