Sort of trying out some quirks in javascript:
First I did
console.log("5" + 1);
This prints 51, this is normal right, both number and string have a + operator, but since string is the first variable it will convert 1 to a string.
Now when I did this:
console.log(1 + "5")
I expected output to be 6, as I thought it would convert string to a number.
However, the magic output was 15.
Could anyone more experienced in javascript brighten this up for me?
Quoting ECMAScript spec The Addition operator ( + ) section:
If Type(lprim) is String or Type(rprim) is String, then
Return the String that is the result of concatenating ToString(lprim) followed by ToString(rprim)
So the order doesn't matter here.
console.log(1 + "5")
I expected output to be 6, as I thought it would convert string to a number. ...
But then what would you expect if you had written the following?
console.log(1 + " fine day")
or
console.log(1 + " answer(s) to my question")
There can be no assurance as a general rule that a string is convertible to a number. But any number can be converted to a string. That's why the conversion rules are written to move toward a type that is compatible. (In contexts where you as a programmer know that a string can be safely converted to a number, then you can do so explicitly so that the + operation is between two numbers. But that is not true in general for strings.)
In other contexts, this is also why small ints and low precision floats would be converted to large ints or double precision floats when operating on mixed types that the latter types. You can safely convert the limited forms into the larger forms, but you cannot safely go in the other direction in general. A small int can be represented as a big int or a double, but the other direction is not generally a safe conversion.
So conversion rules for operation on mixed types are written as much as is feasible to move toward mutually compatible types that are safe common types. It is left to the programmer to write explicit conversions for the special cases where a more general type can be safely converted to a more limited type.
In both cases the value will be converted to a string.
When you add a number to a string or a string to a number, the result is a string.
Simply use parseInt(value) or toString(value) to force the conversion.
You can try code :
console.log(1 + parseInt("5"))
=> 6
Concatenation also uses + in Javascript.
var result = "String" + number + obj;
// is equivalent to
string result = "String" + number.ToString() + obj.ToString();
However thing is, in C# / .net you could do the same thing, and you will get the same result - System.Console.WriteLine("result is " + 10 + 20);.
In JavaScript (and C# for that matter) strings are immutable. They can never be changed, only replaced with other strings. You're probably aware that combined + "String" doesn't directly modify the combined variable - the operation creates a new string that is the result of concatenating the two strings together, but you must then assign that new string to the combined variable if you want it to be changed.
The argument about using mathematical operators to do string concatenation is arguably an "incorrect" argument, but there's also an argument to be made that using + to do a lot of string concatenation can be very slow.
Related
There are a few expressions that are commonly seen in JavaScript, but which some programming purists will tell you are never a good idea. What these expressions share is their reliance on automatic type conversion — a core feature of JavaScript which is both a strength and a weakness, depending on the circumstances and your point of view.
Type coercion and type conversion are similar except type coercion is when JavaScript automatically converts a value from one type to another (such as strings to numbers). It's also different in that it will decide how to coerce with its own set or rules. I found this example useful because it shows some interesting output behavior illustrating this coercive behavior:
const value1 = '5';
const value2 = 9;
let sum = value1 + value2;
console.log(sum);
In the above example, JavaScript has coerced the 9 from a number into a string and then concatenated the two values together, resulting in a string of 59. JavaScript had a choice between a string or a number and decided to use a string.
The compiler could have coerced the 5 into a number and returned a sum of 14, but it did not. To return this result, you'd have to explicitly convert the 5 to a number using the Number() method:
sum = Number(value1) + value2;
From an MDN glossary entry I wrote here: https://developer.mozilla.org/en-US/docs/Glossary/Type_coercion edited by chrisdavidmills
Does JavaScript support automatic type conversion?
Yes. It's usually called type coercion, but conversion is perfectly accurate.
For instance:
console.log("Example " + 42);
"automatically" converts 42 (a number) to string. I put "automatically" in quotes because it's done by the + operator, in a clearly-defined way.
Another example is that various operations expecting numbers will convert from string (or even from object). For instance:
const obj = {
valueOf() {
return 2;
}
};
const str = "10";
console.log(Math.max(obj, str)); // 10
console.log(Math.min(obj, str)); // 2
The rules JavaScript uses are clearly and completely defined in the specification. That doesn't prevent people from frequently being surprised by some of them, such as that +"" is 0.
Using the node.js console, I get the following unexpected results:
> 2 + "3"
"23"
> 2 * "3"
6
Why does the first example favor string concatenation and integer multiplication in the second example? I would not expect concatenation between different types, but rather an error to be thrown. If this is the behavior in JS, how can I predict the type of the final result?
In JavaScript the + operator serves as both addition and concatenation (joining two strings together) and will default to concatenation when one of the two values is a string.
Since you are using it between an integer and a string it will default to concatentation. If you ever need to force the addition operation you will need to make sure all of your values are numbers. You can do this with parseInt() and parseFloat() functions.
2 + parseInt("3"); // 5
The * operator is for multiplication only and as such it will automatically cast strings to numbers to perform the operation.
Given the above there's another trick you can use to force string numbers to actually become numbers which is multiplying them by 1 *1.
2 + "3"*1; // 5
According to ECMAScript 2015 Language Specification (Addition operator, Multiplicative operators), the evaluation of additive expression is (lprim is the left primitive (lval converted to primitive), rprim is the right one):
...
If Type(lprim) is String or Type(rprim) is String, then
Let lstr be ToString(lprim).
ReturnIfAbrupt(lstr).
Let rstr be ToString(rprim).
ReturnIfAbrupt(rstr).
Return the String that is the result of concatenating lstr and rstr.
Let lnum be ToNumber(lprim).
ReturnIfAbrupt(lnum).
Let rnum be ToNumber(rprim).
ReturnIfAbrupt(rnum).
Return the result of applying the addition operation to lnum and rnum.
The evaluation of multiplicative expression is:
...
Let lnum be ToNumber(leftValue).
ReturnIfAbrupt(lnum).
Let rnum be ToNumber(rightValue).
ReturnIfAbrupt(rnum).
Return the result of applying the MultiplicativeOperator
You can see that if it is an additive expression, it is first to check whether there is a String. If there is a String, string concatenation is executed. Otherwise, the values are converted to Number and an addition operation is executed.
If it is a multiplicative expression, it would always convert values to Number and deliver a multiplicative operation.
parseFloat("10.1") + parseFloat("32.3")
vs
+ "10.1" + + "32.3"
both statement will produce the same result 42.4
using this statement:
+ "10.1" + + "32.3"
Why does + act like a parse and how each statement affects the performance in the program?
JavaScript uses implicit conversions. The unary + only accepts numbers, so, when you give it a string, it converts it into a number. JavaScript does this by parsing the string as a number. Since JavaScript doesn't have an integer type, it is always parsed as a floating point number.
To answer the performance question: jsperf.
From my tests, the unary operator + is 8 times faster than parseFloat.
I'd guess this has to do with the expense of function calls in JS, etc.
I know that literal numbers do not require quotes around the value. For instance, var x=123; is acceptable and does not need to be var x='123'; or var x="123";.
That being said, is there anything wrong with quoting a literal number?
If the "number" was a zipcode or database record ID, and not a number in the normal sense which might be used in arithmetic, would the answer be different?
It isn't a number. Quoting a number makes it a string, which can make for some differences in the way they're handled. For example:
var a = 1;
var b = '33';
console.log(a + b === 34); // false
console.log(a + b === '34'); // true
Strings also have different types and methods for manipulating them. However, for most of the numeric operators (-, /, *, and other bitwise operators), they convert the string form to its numeric equivalent before performing the operation.
There are also a few differences where numbers are not stored with their exact value in some cases, due to the nature of the floating point format JavaScript numbers are stored in. Strings avoid this problem, though it is much harder to manipulate them. Converting these back to numbers reintroduces these issues. For example, see this:
var recordID = 9007199254740992;
var previousID = recordID;
recordID += 1;
console.log(recordID === previousID); // true
Adding quotes makes the number a string literal and so serves a different purpose than the Number literal defined without quotes.
JavaScript has the concept of type coercion which might have confused you.
Quoting makes a string of a number. It means that for example + operation will concatenate instead of add:
var a = 'asdf';
var b = '20';
var c = a + b; // asdf20
Here is a great explanation of what is going on.
I know that literal numbers do not require quotes around the value. For instance, var x=123; is acceptable and does not need to be var x='123'; or var x="123";.
It's not a matter of required Vs not required (optional)
Using quotes (single or double) you state that it is a string (a sequence of characters - no matter if they're all digits)
If you don't place quotes you state it is a number.
That being said, is there anything wrong with quoting a literal number?
No if the entity it represents is not actually a number but a string. So...
If the "number" was a zipcode or database record ID, and not a number in the normal sense which might be used in arithmetic, would the answer be different?
If the number is a zipcode it may make sense to put quotes, because it is a "code", not a number and is not subject to arithmetics operations.
You're not going to divide a zipcode by 2 or sum two zipcodes because that would not make sense.
But instead of deciding to use quotes or not based on what the value represents I suggest you to consider the problem from the language perspective
You should understand and keep always in mind how do the language's operators behave when you use a string instead of a number in an expression (assignment or comparison).
Why is it that this code evaluates to:
10 + "10" => "1010"
"10" + 10 => "1010"
and why does it not work like this:
10 + "10" => 20 // the number comes first
"10" + 10 => "1010" // the string comes first
EDIT:
More specifically, where in the implementation of the interpreter does it do this? Or, how does it do this?
The ECMAScript 262 Specification codifies the JavaScript language (JavaScript is actually the Mozilla implementation of ECMAScript). In any case, things are relatively easy to find in Annotated ES5 which I usually consult.
See 11.6.1 The Addition operator ( + ):
The addition operator either performs string concatenation or numeric addition.
The production AdditiveExpression : AdditiveExpression + MultiplicativeExpression is evaluated as follows:
Let lref be the result of evaluating AdditiveExpression.
Let lval be GetValue(lref).
Let rref be the result of evaluating MultiplicativeExpression.
Let rval be GetValue(rref).
Let lprim be ToPrimitive(lval).
Let rprim be ToPrimitive(rval).
If Type(lprim) is String or Type(rprim) is String, then
Return the String that is the result of concatenating ToString(lprim) followed by ToString(rprim)
Return the result of applying the addition operation to ToNumber(lprim) and ToNumber(rprim). See the Note below 11.6.3.
+ is a concatenation operator and as well as arithmetic operator in Javascript. If it finds that operator is used between string and number then it concatenates that number into string else if you using operator for two integers then result will also be integer.
So,
STRING + STRING = STRING
STRING + INTEGER = STRING
INTEGER + STRING = STRING
INTEGER + INTEGER = INTEGER
When comparing values that have different types, JavaScript uses a complicated and confusing set of rules. In general, it just tries to convert one of the values to the type of the other value (as we can see in your question). This is often noted as automatic type conversion.
Let's take a look at your code:
10 + "10" => "1010"
"10" + 10 => "1010"
In JavaScript, if any non-string value is added to a string, the value is automatically converted to a string before it is concatenated. Thus JavaScript, regardless of the ordering of your integer or string values, treats any integer as a string.
You should know, however, that JavaScript does not apply this to all arithmetic operators. For example, if we were to multiply our values we would get:
10 * "10" => 100
"10" * 10 => 100
"ten" * 10 => NaN
Now, why does Javascript do this? Well, you could argue it's for convenience sake. There are many instances were you might need to concatenate two values into a string. On the contrary, you can never multiply an integer with a character string, as we can see in the last example above.
unfortunately, this is how Javascript works