Data Analysis
NaN Values
Data Cleaning
Programming
Data Science

How to check for NaN values

ML System Design practice on Codemia

Design recommenders, ranking systems and training pipelines the way ML interviews actually ask for them, with worked solutions.

Practice ML system design

Introduction

NaN handling is a core data-quality step in analytics and machine learning pipelines. NaN means “not a number,” and it behaves differently from normal values, including the rule that NaN != NaN. If you do not check for NaNs explicitly, filters, aggregations, and model training can silently degrade.

This article shows reliable NaN detection patterns across common Python tools and practical handling strategies.

Core Sections

1) NaN checks in NumPy

python
1import numpy as np
2
3arr = np.array([1.0, np.nan, 3.0])
4mask = np.isnan(arr)
5print(mask)           # [False  True False]
6print(arr[~mask])     # [1. 3.]

np.isnan is vectorized and fast for numeric arrays.

2) NaN checks in pandas

python
1import pandas as pd
2
3df = pd.DataFrame({"a": [1.0, None, 3.0], "b": ["x", "y", None]})
4print(df.isna())
5print(df["a"].isna().sum())

Use isna or isnull (aliases) for DataFrame-level missing-value detection.

3) Scalar checks in pure Python

python
1import math
2
3x = float("nan")
4print(math.isnan(x))     # True

Do not compare directly with == because NaN is never equal to itself.

4) Filtering and imputation workflow

python
1# drop rows with missing numeric target
2clean = df.dropna(subset=["a"])
3
4# fill NaN for model input
5filled = df["a"].fillna(df["a"].median())

Pick drop vs fill based on data semantics, not convenience.

5) Validation in pipelines

Add assertive checks before training or export.

python
assert not np.isnan(arr).any(), "NaN detected in training features"

Failing fast prevents downstream debugging complexity.

6) Production checklist for NaN detection and remediation

To move this pattern from tutorial code into dependable production behavior, define a repeatable validation workflow before rollout. Start with three explicit acceptance metrics: correctness, reliability, and latency. Correctness should be measured against known fixtures or golden outputs, reliability should include error-rate and retry outcomes, and latency should use tail metrics such as p95 or p99 rather than simple averages. Running these checks once locally is not enough; they should execute in CI and, when possible, in a staging environment that resembles production data volumes and dependency behavior.

Next, capture environmental assumptions where maintainers can see them. Document runtime version, library versions, required environment variables, and external service dependencies. Many regressions happen because one assumption changes silently: a runtime upgrade, a minor package update, or a different default configuration in a deployment environment. Add at least one negative test that simulates a realistic failure mode, such as timeout, malformed input, permission issue, or missing artifact. These tests verify that failure handling is explicit and observable rather than hidden.

Operational readiness also requires ownership and rollback clarity. Define who responds when this component fails, what threshold triggers investigation, and what rollback path can be executed quickly. If the feature can be gated, prefer a flag-driven rollout so you can disable behavior without emergency code changes. Even for small utilities, this discipline prevents long incident timelines.

bash
1# Example pre-release validation sequence
2make lint
3make test
4./scripts/smoke_check.sh

Finally, keep a brief limitations note. State clearly what this implementation handles and what it intentionally does not optimize. That helps future contributors avoid accidental misuse and keeps design decisions grounded in explicit tradeoffs. Revisit this checklist after major framework or infrastructure upgrades, because behavior that was safe under one runtime may degrade under another if assumptions are no longer valid.

Common Pitfalls

  • Comparing values directly to np.nan instead of using dedicated NaN checks.
  • Mixing string placeholders like "NA" with actual numeric NaN handling.
  • Filling missing values without documenting the imputation rule.
  • Ignoring NaNs in target labels, causing training metric distortion.
  • Running statistical functions without understanding default NaN behavior.

Summary

NaN checks should be explicit and early in every data pipeline. Use np.isnan, pandas.isna, and math.isnan in the right context, then choose clear handling rules for drop or impute. Reliable NaN strategy improves model quality and reduces hidden data bugs.


Related reading
Free course
Beginner
7 lessons
2 hours
Tackling System Design Interview Problems

A short course that equips you with the skills to approach system design interviews methodically.

Start the free course
Track what you have practised

A free account saves your progress, solutions and study plan across every problem on Codemia.

ML System Design practice on Codemia

Design recommenders, ranking systems and training pipelines the way ML interviews actually ask for them, with worked solutions.

Practice ML system design

All Rights Reserved.