Watch 10 video solutions for Valid Number, a hard level problem involving String. This walkthrough by NeetCode has 391,872 views views. Want to try solving it yourself? Practice on FleetCode or read the detailed text solution.
Given a string s, return whether s is a valid number.
For example, all the following are valid numbers: "2", "0089", "-0.1", "+3.14", "4.", "-.9", "2e10", "-90E3", "3e+7", "+6e-1", "53.5e93", "-123.456e789", while the following are not valid numbers: "abc", "1a", "1e", "e3", "99e2.5", "--6", "-+3", "95a54e53".
Formally, a valid number is defined using one of the following definitions:
An integer number is defined with an optional sign '-' or '+' followed by digits.
A decimal number is defined with an optional sign '-' or '+' followed by one of the following definitions:
'.'.'.' followed by digits.'.' followed by digits.An exponent is defined with an exponent notation 'e' or 'E' followed by an integer number.
The digits are defined as one or more digits.
Example 1:
Input: s = "0"
Output: true
Example 2:
Input: s = "e"
Output: false
Example 3:
Input: s = "."
Output: false
Constraints:
1 <= s.length <= 20s consists of only English letters (both uppercase and lowercase), digits (0-9), plus '+', minus '-', or dot '.'.Problem Overview: You receive a string and must determine whether it represents a valid numeric value. The string may contain digits, optional signs (+/-), decimal points, and scientific notation using e or E. The challenge is validating the exact structure while rejecting malformed numbers like multiple decimals, misplaced signs, or invalid exponent formats.
This problem is fundamentally about controlled string parsing. You scan characters and enforce rules about where digits, decimal points, and exponent markers are allowed.
Approach 1: Using Regular Expressions (O(n) time, O(n) space)
A concise way to validate the format is using a regular expression that describes all valid number patterns. The regex captures optional leading signs, integer or decimal formats, and an optional exponent part like e+10. The engine scans the string and checks whether it matches the pattern exactly.
The key insight is that numeric formats follow a predictable grammar. A typical pattern allows: optional sign → digits with optional decimal → optional exponent with sign and digits. Regex works well when the validation rules are fixed and clearly definable. However, the pattern can become difficult to read or debug in interviews.
This approach runs in O(n) time because the regex engine processes the string linearly, and uses O(n) space depending on the implementation. It is quick to implement in languages like Python or JavaScript.
Approach 2: Iterative Parsing (O(n) time, O(1) space)
The iterative parsing approach scans the string once and tracks what has been seen so far. You maintain boolean flags such as seenDigit, seenDot, and seenExponent. Each character is processed according to strict rules:
Digits are always valid and mark that a number exists. A decimal point is valid only before the exponent and only once. The exponent character (e/E) must appear after at least one digit and resets the requirement for digits afterward. Signs are allowed only at the start or immediately after an exponent.
This effectively implements a lightweight parsing state machine without explicitly defining states. The scan is linear, so the time complexity is O(n), and only a few flags are stored, giving O(1) space.
Recommended for interviews: The iterative parsing solution is what interviewers typically expect. It demonstrates that you understand the grammar of numeric strings and can enforce constraints during a single pass. The regex approach works and is concise, but interviewers often prefer seeing explicit logic that validates each rule.
| Approach | Time | Space | When to Use |
|---|---|---|---|
| Regular Expression Validation | O(n) | O(n) | Quick implementation when regex support is strong and readability is not a concern |
| Iterative Parsing with Flags | O(n) | O(1) | Interview settings or production code where explicit validation logic is preferred |