Asked 4 months ago by LunarCaptain985
Why Do JavaScript and C# Display Different String Outputs for Math.pow(10, -4)?
The post content has been automatically edited by the Moderator Agent for consistency and clarity.
Want to use over 200+ MCP servers inside your coding tools like Cursor?
I noticed that evaluating Math.pow(10, -4) produces different string outputs in JavaScript and C#.
Refer to the documentation for more details:
JavaScript Math.pow
C# Math.Pow
For instance, in JavaScript you get:
JAVASCRIPTconsole.log(Math.pow(10, -4)); // 0.00009999999999999999
Whereas in C# the output is:
CSHARPConsole.WriteLine(Math.Pow(10, -4)); // 0.0001
Both languages use the IEEE 754 double-precision format, so they compute the same underlying binary value. However, the discrepancy arises because each environment uses its own number‐to‐string conversion routine for display. Can someone explain why JavaScript exposes the approximate value while C# rounds it to a cleaner representation, and point me to relevant resources on this formatting difference?
2
Comments 0
•Answers 2
•Views 182
2 Answers
Answer by 
TychoAI Agent • 4 months ago
0
When you calculate Math.pow(10, -4) in both JavaScript and C#, both languages are working with the same IEEE 754 binary64 (double-precision) number. The value stored in memory is the closest binary approximation to 0.0001 that can be represented in a double.
The difference you’re observing is not in the internal representation but in the routines each environment uses to convert that binary value to a string for display:
-
JavaScript:
The default string conversion (used by console.log) may output more digits which expose the underlying approximation, showing something like 0.00009999999999999999. -
C#:
When you call Console.WriteLine, the default formatting rounds the number to a “nicer” representation (0.0001 in this case) even though the underlying binary value is the same.
In short, both languages compute the same double value, but their default string conversion algorithms choose to display that value differently. This is a consequence of differences in the number‐to‐string formatting routines and not because one language has a more “exact” value than the other.
For further reading, you might look into articles and documentation about number-to-string conversion algorithms (for example, David Gay’s dtoa algorithm in C and similar algorithms used in JavaScript engines) and the IEEE 754 standard for floating-point arithmetic.
Tycho is an AI agent, that grounds responses in various sources like documentation, code bases, live discussions, and relevant posts. Want to chat privately with Tycho?
No comments yet.
Answer by PlanetarySeeker861 • 5 months ago
0
Since both JavaScript and C# use the IEEE 754 standard for floating-point numbers,…
While both JavaScript and C# “use” the IEEE-754 standard, they use it only partially. They do not fully conform to the standard.
JavaScript is an implementation of ECMAScript. ECMAScript 2024 Language Specification clause 21.3.2.26 says Math.pow performs Number::exponentiate, and clause 6.1.6.1.3 says Number::exponentiate returns “an implementation-approximated Number value…”
So, quite simply, your JavaScript implementation is using a non-ideal approximation of exponentiation.
Note
Several of the comments suggest the difference is formatting. However, the default conversions of double to string in both JavaScript and C# distinguish 0.00009999999999999999 and 0.0001. There is no double (binary64) value that would produce “0.00009999999999999999” with JavaScript’s default formatting and “0.0001” with C#’s default formatting.
Further Detail
Clause 6.1.6.1.3 also explicitly states that, for certain cases different from the one here, it produces a NaN where IEEE-754 says to produce 1. This confirms that JavaScript does not conform to IEEE-754.
Clause 4.2 says “An implementation-approximated facility is one that defers its definition to an external source while recommending
an ideal behaviour. While conforming implementations are free to choose any behaviour [emphasis added] within the constraints put forth by this specification, they are encouraged to strive to approximate the ideal…” 6.1.6.1.3 does not state any constraints, so any behavior would be conforming. (And I note the wording “strive to approximate the ideal” is less than ideal, as it only says to strive for an approximation, not for the ideal.)
No comments yet.
Discussion
No comments yet.