Learning Objectives
By the end of this lesson you will be able to:
- Explain how scientific notation is parsed in different programming environments
- Identify inputs that are valid in scientific notation but cause parser failures
- Use scientific notation systematically to probe numeric field limits
What is Scientific Notation?
Scientific notation expresses numbers as a coefficient times a power of 10:
1e10= 10,000,000,000 (ten billion)1.5e-7= 0.000000151E+308= 1.7... × 10^308 (near Double.MAX_VALUE)1e-324= the minimum positive Double1e999= larger than any floating-point type can represent →Infinity1e-400= smaller than the minimum positive Double → underflows to0.0
How Parsers Handle It
Different parsing contexts handle scientific notation differently:
| Context | 1e10 |
1e999 |
abc |
|---|---|---|---|
Java Double.parseDouble() |
1.0×10^10 | Infinity | NumberFormatException |
JavaScript parseFloat() |
1.0×10^10 | Infinity | NaN |
PostgreSQL FLOAT8 cast |
1.0×10^10 | "value out of range for type double precision" | Error |
Java Integer.parseInt() |
NumberFormatException | NumberFormatException | NumberFormatException |
Key insight: 1e10 might be valid for a double field but invalid for an integer field. A backend that parses all inputs as double and then converts to integer may silently lose precision.
Scientific Notation as a Testing Tool
Scientific notation lets you express extreme values concisely in a text input:
- Overflow test: Enter
1e400— if the field is a double, this should either be rejected or return Infinity - Underflow test: Enter
1e-400— this should be rejected or treated as zero - Near-limit test: Enter
1.7976931348623157e308— this is exactly Double.MAX_VALUE
This is far more practical than typing out the full 308-digit number.
What to Test
For any numeric text field:
1e10— valid for float; invalid for int1e400— overflow for any type1e-400— underflow for double (rounds to 0)1.5E7(uppercase E) — some parsers are case-sensitive1e(incomplete) — should cause parse error1.2.3e4— should cause parse error1e1.5(fractional exponent) — invalid in most parsers
The Truncation Trap
Some backends parse user input as a double, then convert to an integer:
double d = Double.parseDouble(userInput); // "1e10" → 10000000000.0
int i = (int) d; // 10000000000.0 cast to int → silently truncates!
1e10 fits in a double (valid), but not in an Int32 (max 2.1B). The cast silently truncates to a wrong value. Test with 1e10 when a field is supposed to accept integers.
Pro Tip: Always test
1e10,1e-10, and1e400as a minimum scientific notation test suite for any numeric field. Three inputs, major coverage.
Key Takeaways
- Scientific notation is valid input for float fields but may break integer parsers
1e999→ Infinity;1e-400→ 0.0 in double — both are important edge cases- Test both lowercase
eand uppercaseE— parsers may differ - Incomplete notation (
1e,1e1.5) should produce a clear parse error