Why does console.log(0123); log the integer . 83? I'm not sure why it would and don't really have an idea either.
Because it's interpreted as an octal number, and octal 123 corresponds to decimal 83 (64 + 16 + 3).
From MDN:
Leading 0 (zero) on an integer literal, or leading 0o (or 0O)
indicates it is in octal. Octal integers can include only the digits
0-7.
Because the leading 0 (zero) 0o or 0O on an integer indicates an octal number!!
Octal numbering system is used less nowadays and has almost disappeared as a digital base number system. Hexadecimal numbering system is so popular now!
Related
Why does console.log(parseInt(0o22,8)) output 1?
0oNNN is ECMAScript 2015 syntax for literal octal numbers.
0o22 is 18 in decimal. parseInt needs a string, so this integer 18 is coerced to the decimal string '18' by parseInt. And since 8 is not a valid digit in base-8, parseInt bails out after the first digit and returns 1.
From MDN documentation for parseInt:
If parseInt encounters a character that is not a numeral in the specified radix, it ignores it and all succeeding characters and returns the integer value parsed up to that point. parseInt truncates numbers to integer values. Leading and trailing spaces are allowed.
See also: How do I work around JavaScript's parseInt octal behavior?
I'm taking a numerical input as an argument and was just trying to account for leading zeroes. But it seems javascript converts the number into octal before I can do anything to the number. The only way to work around it so far is if I pass the number as a string initially but I was hoping there'd be another way to convert it after it is passed? So far tried (using 017 which alerted me to the octal behaviour):
017.toString(10) // 15
parseInt(017,10) // 15
017 + "" //15
new Number(017) //15
new Number('017') //17
parseInt('017', 10) // 17
So given
function(numb) {
if (typeof numb === number) {
// remove leading zeroes and convert to decimal
}
else {
// use parseInt
}
}
'use strict' also doesn't seem to solve this as some older posts have suggested. Any ideas?
If you take "numerical input", you should always definitely guaranteed have a string. There's no input method in this context that I know that returns a Number. Since you receive a string, parseInt(.., 10) will always be sufficient. 017 is only interpreted as octal if written literally as such in source code (or when missing the radix parameter to parseInt).
If for whatever bizarre reason you do end up with a decimal interpreted as octal and you want to reverse-convert the value back to a decimal, it's pretty simple: express the value in octal and re-interpret that as decimal:
var oct = 017; // 15
parseInt(oct.toString(8), 10) // 17
Though because you probably won't know whether the input was or wasn't interpreted as octal originally, this isn't something you should have to do ever.
JavaScript interprets all numbers beginning with a 0, and containing all octal numerals as octals - eg 017 would be an octal but 019 wouldn't be. If you want your number as a decimal then either
1. Omit the leading 0.
2. Carry on using parseInt().
The reason being is that JavaScript uses a few implicit conversions and it picks the most likely case based on the number. It was decided in JavaScript that a leading 0 was the signal that a number is an octal. If you need that leading 0 then you have to accept that rule and use parseInt().
Source
If you type numbers by hand to script then not use leading zeros (which implicity treat number as octal if it is valid octal - if not then treat it as decimal). If you have number as string then just use + operator to cast to (decimal) number.
console.log(+"017")
if (021 < 019) console.log('Paradox');
The strict mode will not allow to use zero prefix
'use strict'
if (021 < 019) console.log('Paradox');
i am reading a book named "CODE" there i read a sentence "the octal representations of bytes range from 000 to 377" i don't understand how ? where does 377 comes from ? could some one please explain it thanks in advance .
The octal value 0377 represents 255 in decimal which would be the range of a single byte.
The reason why hexadezimal and octal numbers are usefull is, because in hex a single digit represents exactly four bits, while in octal a single digits reprsents exactly three bits. this makes it much easier to convert to binary reading when dealing with flags, in contrast to decimal, where you'd have to know which numbers represent which bit, and do some calculation.
If you have an arbitrary bitmask, you can easily tell with one glance which bits are set if you use either hex or octal, which is not so easy with decimal numbers.
377 octal is 255 decimal, which is highest possible value of one byte.
Today a byte practically always consists of 8 bits. With 8 bits, you can represent 2^8 (256) different values (typically from 0-255 (unsigned)). And as others explained already 255 == ff (base 16) == 255 (base 10) == 0377 (base 8) == 11111111 (base 2).
This value comes out very nice in hexadecimal, since single digit represents four bits (as there are 16 (2^4) hexadecimal digits), meaning two digit hexadecimal number always fit one byte.
Octal numeral system is pretty much out of use. Once it was much more common, as some computers used word sizes divisible by three (as explained in this wikipedia article on Octal).
This question already has answers here:
How to parseInt a string with leading 0
(6 answers)
Closed 8 years ago.
avar = "0000013482000000";
t = parseInt(avar);
When I run that, t is 92 for some reason. If I remove the leading 0's, then it works just fine. Why would that be?
Try this:
avar = "0000013482000000";
t = parseInt(avar,10);
Some browsers might assume that it is an octal number if the string starts with 0.
However, ,10 is not required in modern browsers with new ECMAScript standards because they will always be considered as decimal unless specified or starts with 0x (hexadecimal).
Chrome is one of those browsers that has a default radix of 10.
Reference: ECMAScript Language Specification Page 104
The parseInt function produces an integer value dictated by interpretation of the contents of the string
argument according to the specified radix. Leading white space in string is ignored. If radix is undefined or 0,
it is assumed to be 10 except when the number begins with the character pairs 0x or 0X, in which case a radix
of 16 is assumed. If radix is 16, the number may also optionally begin with the character pairs 0x or 0X.
Use the second parameter (radix):
t = parseInt(avar, 10);
To specify that the number should be parsed in base 10.
From the MDN docs:
If radix is undefined or 0 (or absent), JavaScript assumes the following:
If the input string begins with "0x" or "0X", radix is 16 (hexadecimal) and the remainder of the string is parsed.
If the input string begins with "0", radix is eight (octal) or 10 (decimal). Exactly which radix is chosen is implementation-dependent. ECMAScript 5 specifies that 10 (decimal) is used, but not all browsers support this yet. For this reason always specify a radix when using parseInt.
If the input string begins with any other value, the radix is 10 (decimal).
And in reference to ECMAScript 5:
The parseInt function produces an integer value dictated by interpretation of the contents of the string argument according to the specified radix. Leading white space in string is ignored. If radix is undefined or 0, it is assumed to be 10 except when the number begins with the character pairs 0x or 0X, in which case a radix of 16 is assumed. If radix is 16, number may also optionally begin with the character pairs 0x or 0X.
Reference:
https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/parseInt
Parsing a number with leading zeros causes the number to be treated as octal. To override this you need to set the radix parameter of parseInt to 10 (base 10 as opposed to base 8).
parseInt assumes octal notation if you have a leading zero, so you want to pass in a radix as the second parameter, telling the function to parse the string as a base 10 int.
parseInt(avar, 10)
should fix it.
From what I understand, octal literals (of the form 023) are not valid in ECMAScript 5, but are widely supported. In ECMAScript 6, they are newly supported in the format 0o23 or 0O23. What confuses me is the behavior of numbers that are not valid octal numbers, but have a preceding zero (019). These seem to behave as normal, decimal numbers.
So without strict mode, I can get things like 022 === 018 (true), because 022 is interpreted as octal, and presumably 018 is treated as decimal since it can't be octal.
In strict mode, I get an error when using a valid octal number in that format (eg 022), but not when using a zero-prefixed number that can't be a valid octal number (eg 018).
This seems very odd to me, like JS (strict-mode) is telling me that I can put a 0 in front of my number, as long as it is an INVALID octal. In ES6 (or later), will zero-prefixed numbers (possible octals or otherwise) be invalid, or treated as decimals?
This is a documented feature:
Decimal literals can start with a zero (0) followed by another
decimal digit, but If all digits after the leading 0 are smaller than
8, the number is interpreted as an octal number. This won't throw in
JavaScript.
If you want to force treating a number as octal you can use new literal form 0o (or 0O) introduced in ES6.