This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Large numbers erroneously rounded in Javascript
I am experiencing some strange behavior when working with numbers in javascript. When I use the following code:
CLICK HERE
I get the number 9200000000032336 in my console. I think it most be something with rounding or max values for numbers, but I don't understand it completely. Anyone?
I'm not a Javascript expert, but it sounds like your number is being stored as an IEEE-754 64-bit floating point number. Certainly that's what I get from C# code which will display the exact value of a double:
double d = 9200000000032337;
Console.WriteLine(DoubleConverter.ToExactString(d));
(Using my own DoubleConverter class.) My output is the same as yours: 9200000000032336
Floating point values only ever hold a certain number of significant digits accurately - and when the numbers get high enough, even integers can't be stored exactly.
ECMA-262 seems to confirm this:
4.3.19
Number value
primitive value corresponding to a double-precision 64-bit binary format IEEE 754 value
and from section 7.8.3 (numeric literals):
A numeric literal stands for a value of the Number type. This value is determined in two steps: first, a
mathematical value (MV) is derived from the literal; second, this mathematical value is rounded as described
below.
Section 8.5 contains more details.
Related
This question already has answers here:
How to avoid scientific notation for large numbers in JavaScript?
(27 answers)
Closed 6 years ago.
I try to get
Math.pow(2,1000);
The result is " 1.2676506002282294e+30 "
I need the number without Euler's number "e+30"
That's scientific notation, not Euler's number.
If you want to show the number without the e+NN part:
convert it to a string
parse the e+NN part
shift the decimal place the appropriate number of digits
return the output as a string
be aware that doing so will lead to inaccurate values for some calculations due to how floating point arithmetic works.
With very large numbers, JavaScript displays them in scientific notation. This is because it is very expensive and unreadable to list them.
For your example, it basically means
1.2676506002282294 * 10 ^ 30
You take the number and then multiply it by 10 to the 30th power.
Calculators often use "E" or "e" like this: 1.8004E+94
6E+5 is the same as 6 × 10^5
To get it without this notation, simply use smaller numbers as the exponent.
Example: Math.pow(2,10)
Mathisfun provides an excellent article on scientific notation. Check it out here
https://www.mathsisfun.com/numbers/scientific-notation.html
Euler's number is a constant that is the base of a natural number. It's an irrational number, meaning its digits go on forever. The first couple digits are 2.7182818284
This question already has answers here:
What is JavaScript's highest integer value that a number can go to without losing precision?
(21 answers)
Closed 8 years ago.
Can anybody solve the following problem with javascript
var i = 10152233307863175;
alert(i.toString());
alert shows value 10152233307863176. Any solution. Problem is when I get json object on client and when string is converted to json it contains wrong values.
This is a limitation in the precision of the numeric data format that javascript uses (double precision floating point).
The best way of storing that value, assuming you don't need to do any mathematical operations, is storing it as a string in the first place.
MDN has this to say about numbers in JavaScript.
Numbers in JavaScript are "double-precision 64-bit format IEEE 754 values", according to the spec.
There is no real integers in JavaScript. According to this source:
ECMAScript numbers are represented in binary as IEEE-754 (IEC 559) Doubles, with a resolution of 53 bits, giving an accuracy of 15-16 decimal digits; integers up to just over 9e15 are precise, ...
Your number 10152233307863175 contains 17 digits. Since the number is represented as a floating point number, JavaScript tries to do it's best and set bits in a way that the resulting number is closest to the supplied number.
So in JavaScript, 111111111111111111111 == 111111111111111110000. Just type any long number – at least about 17 digits – to see it in action ;-)
That is because JavaScript uses double-precision floating-point numbers, and certain very long numeric literals can not be expressed accurately. Instead, those numbers get rounded to the nearest representable number possible. See e.g. What is JavaScript's highest integer value that a Number can go to without losing precision?
However, doing the math according to IEEE-754, I found out that every number inside [111111111111111106560, 111111111111111122944] will be replaced by 111111111111111114752 internally. But instead of showing this ...4752 number, it gets displayed as 111111111111111110000. So JavaScript is showing those trailing zeros which obfuscates the real behavior. This is especially annoying because even numbers like 263, which are accurately representable, get "rounded" as described.
So my question is: Why does JavaScript behave like this when displaying the number?
JavaScript integers can only be +/- 253, which is:
9007199254740992
One of your numbers is
111111111111111106560
which is considerably outside of the range of numbers that can accurately represented as an integer.
This follows the IEEE 754:
Sign bit: 1 bit
Exponent width: 11 bits
Significand precision: 53 bits (52 explicitly stored)
EDIT
The Display of numbers is sometimes rounded by the JavaScript engine, yes. However, that can be over-ridden using the toFixed method. (Warning, toFixed is known to be broken under some versions of IE).
In your console, type:
111111111111111122944..toFixed(0)
"111111111111111114752"
This question already has answers here:
Javascript toFixed function
(6 answers)
Closed 8 years ago.
When the non fractional part is bigger than 4 the fractional part it is truncated to .3 but when it is smaller than 4 it is rounded to .4.
Examples:
1.nr>4:
5.35.toFixed(1) => 5.3
15.35.toFixed(1) => 15.3
131.35.toFixed(1) => 131.3
2.nr<4:
2.35.toFixed(1) =>2.4
1.35.toFixed(1) =>1.4
Is this kind of behaviour normal?
The problem is that the exact values you're calling toFixed on aren't 1.35 etc... they're the nearest IEEE-754 64-bit representation. In this case, the exact values are:
1.350000000000000088817841970012523233890533447265625
2.350000000000000088817841970012523233890533447265625
5.3499999999999996447286321199499070644378662109375
15.3499999999999996447286321199499070644378662109375
Now look at those values and work out what you'd do in terms of rounding to 1 decimal place.
Basically you're falling foul of the fact that these are floating binary point values, so the value you express in decimal isn't always the value that's actually used. It's just an approximation. In other languages the preferred alternative is to use a type which represents floating decimal point values (e.g. BigDecimal in Java or decimal in C#) but I don't know of anything similar within standard Javascript. You may find some third party libraries though.
This question already has answers here:
Is floating point math broken?
(31 answers)
Closed 9 years ago.
I want to make multiplication using JavaScript.
Multiplication of 2 and 0.15 is 0.3 but 3 and 0.15 is 0.44999999999999996. I want to get 0.45 such as result. How can I do it with JavaScript?
It's a rounding error. You may want to round your number to a fixed amount of digits, like this:
parseFloat((your_number).toFixed(2));
Unfortunately this happens in any language using floating point arithmetic. It's an artifact arising when floating point operations are encoded into binary, operations performed, and decoded from binary to report the answer in a form you'd expect.
Depending on what you want to do with the output, you can call a round()-like function to round to a number of decimal places or compare the output to a value using a (small) number called a tolerance. E.g. two numbers are considered equal if their absolute difference is less than this tolerance.