so the Number() function
works like Number.parseInt()
except it doesn’t take a radix parameter?
I’m OK with not knowing why the answer is 4, for now. If the Babelfish translates Vogon into English I’m ok letting it do its thing. Some day the fish will malfunction and I can burn that bridge later…Not that I’m not interested in why…but sometimes I go too far down the rabbit hole and it gets overwhelming or off-task
…PS I meant the actual math of “the radix thing”. I understand they are both arguments passed into the function
Picking nits and sharing useless trivia, not all humans use base ten. The imperial measurement system is base 12 (dozen, gross, great gross; 12 inches to the foot). And as a counting system, it’s logical.
The ancient Phoenecians were a trading people, and kept remarkable inventories. But rather than counting to five or even nine on one hand (fingers for ones, thumb for five), they would count each knuckled segment on the four fingers - 12 on the left would equal one on the right. A full right hand represented 144, rather than the 100 of the decimal counting system.
Of course, had they known binary, they could have counted to 1023 on both hands. Or, counting knuckles in binary… (2^25)-1, or more than 16 million.
Sorry, you said something about rabbit holes…
No.
The Number
function performs a type conversion. So if you give it a string, it will turn it into a number, if you give it a Boolean, it will turn it into a number, etc. This is called type coercion, coercing one type of value to another type of value.
The parseInt
function produces an integer value by evaluating a string according to whatever the radix value is.
This might seem like a very subtle difference, but the point of the two functions is different (parseInt
uses the Number function as the last step before returning its output).
If you know that a string is going to just be a integer (like, for example in that Euler solution), then there’s not really any point using parseInt – you can just convert it directly to a number. There are a few usecase where it makes sense:
- you have a string which you know has one integer in it somewhere, and you want to extract that integer as an actual number. For example, some logs, or some input that has come from HTML.
- you have some data that uses a number system whose syntax is not supported by JS and you need to perform calculations using it.
The latter is probably the most useful, and I assume it’s the reason the function exists as as a global (rather than being attached to the String
object, for example). JavaScript syntax only supports two number systems (decimal – base 10, and octal – base 8). So there needs to be a way to easily manipulate numbers that are not base 8 or 10. So, what you do is convert them to an integer, and now you can do calculations on them (and if necessary you can convert them back to the original base using the toString
method available to numbers).
So for example, say you want to adjust a colour. Colours on the web are normally defined as a triplet of hexadecimal numbers (base 16). But although that’s very compact and easy to use, it’s difficult to manipulate. It would be easier if we had the RGB components as integers. So:
const hexSalmon = "#FA8072";
// Sorry for the regex, but this just splits
// the above string into an array like:
// ["FA", "80", "72"]
const [rHex, gHex, bHex] = /^#?([a-f\d]{2})([a-f\d]{2})([a-f\d]{2})$/i.exec(hexSalmon);
const rgbSalmon = {
r: parseInt(rHex, 16),
g: parseInt(gHex, 16),
b: parseInt(bHex, 16),
};
// This produces { r: 250, g: 128, b: 114 }