A Call to Fix Scientific Notation: Allow 1e-6.999 in All Programming Languages

J. Rogers, SE Ohio, 11 Apr 2025, 1704

Abstract
Scientific notation in programming languages (1eX) is artificially restricted to integer exponents, despite fractional exponents being mathematically valid and practically useful. This paper argues that all languages should support 1e-6.999 (or equivalent) without syntax errors, as it:

1. Breaks no existing code (since 1eX with fractional X is currently illegal everywhere).

2. Matches human intuition (scientific notation should not arbitrarily restrict exponents).

3. Improves readability (avoids clunky 10**-6.999 workarounds).

4. Is trivial to implement (rewrite 1eX.Y → 10**X.Y at parse time).

We demand that compilers and interpreters stop rejecting valid math and fix this now.

---

1. The Problem

Current (Broken) Behavior

python

Copy

1e6      # Valid  
1e-6     # Valid  
1e-6.999 # SyntaxError (everywhere)  

Instead, programmers must write:

python

Copy

10**-6.999 # Ugly, unintuitive, and harder to read  

Why This Sucks

• It violates the principle of least surprise. If 1e3 means 10³, then 1e3.5 should mean 10³·⁵.

• It forces unnatural workarounds in physics, engineering, and finance code where fractional exponents appear naturally (e.g., EM constants, decay rates, statistical models).

• It’s inconsistent with math notation, where e is not restricted to integers.

---

2. The Solution

Just Fucking Parse It

All compilers/interpreters should:

1. Accept 1eX.Y as valid syntax.

2. Treat it identically to 10**X.Y.

3. Optimize it the same way (constant-fold if possible).

Implementation (Trivial)

Python Example

Currently:

python

Copy

# Python's parser rejects this  
x = 1e-6.999  # SyntaxError  

Proposed fix (in CPython’s parser):

diff

Copy

- if (exponent_has_decimal_point) { raise SyntaxError; }
+ // Just compile it as 10**x.y

C Example

c

Copy

// Current (annoying)  
double x = 1e-6;    // Valid  
double y = 1e-6.999; // Compiler error  

// Proposed (correct)  
double y = 1e-6.999; // Works like pow(10, -6.999)  

JavaScript Example

javascript

Copy

// Today  
1e-6.999; // SyntaxError  

// Tomorrow  
1e-6.999; // === 10 ** -6.999  

---

3. Why This Won’t Break Anything

No Backward Compatibility Issues

• No existing code relies on 1eX.Y being invalid (since it’s always been a syntax error).

• All valid existing code (1e6, 1e-6) continues working unchanged.

No Performance Overhead

• At compile time, rewrite 1e-6.999 → 10**-6.999 (or equivalent).

• Constant-fold when possible (e.g., 1e-6.999 → 1.0000000002377254e-07).

No Parser Ambiguity

• 1eX.Y unambiguously means 10^(X.Y).

• No conflicts with other syntax.

---

4. Who Benefits?

Physics & Engineering

python

Copy

# EM constants (your use case)  
alpha = e**2 * 1e-6.999999999762254 / (Hz_kg * c)  # Clean  

Instead of:

python

Copy

alpha = e**2 * 10**-6.999999999762254 / (Hz_kg * c)  # Clunky  

Finance & Statistics

python

Copy

decay_rate = 1e-2.5  # Exponential decay  

Instead of:

python

Copy

decay_rate = 10**-2.5  # Less readable  

Education

• Students learning scientific notation won’t hit artificial syntax barriers.

• Code will match textbook math notation.

---

5. Call to Action

We demand that all major languages implement this now:

Language	Issue Tracker	Expected Fix
Python	CPython GitHub	Python 3.12+
JavaScript	TC39 Proposals	ES2024+
C/C++	GCC Bugzilla	C23/C++26
Java	OpenJDK	Java 22+

How You Can Help

1. File issues in your language’s tracker.

2. Upvote existing proposals (e.g., Python’s PEP process).

3. Submit patches if you work on compilers.

---

Conclusion

There is no good reason to reject 1e-6.999. It’s a stupid historical limitation that needs to die.

Let’s fix this.

---

Authors:

• [Your Name] (Physicist/Engineer who actually needs this)

• [Co-signers] (People tired of typing 10**x)

License: Public domain. Copy, share, and demand better languages.