Yes, the use of assignment here is a little bit confusing.

Although it is worth noting, that it is not enough to just change += to +, because the order of operations will be different. There should be parentheses to enclose the second part. That suggests me to believe, that the += operator was used here to omit using parens.

That's why I'd prefer something like 'a'.charCodeAt() - 1 instead of a cryptic magic number 97.

Why should it fail? If you sort an empty array you'd get an empty array. No errors here.

I don't think this solution is very readable.

At first we get 3 ifs, but we don't know what are we actually comparing, rand is assigned later.
I also don't see at a first glance what is the condition of repeating the loop and how probable is that.
Since the third digit doesn't influence the result, generating and comparing it seems pointless; it is a noise, which decreases readability.

I could also comment the style, but I actually don't have problems with that (maybe except the indentation), although people generally prefer using spaces between operators.

Just brute force, with manual tweaking of parameters.

The test cases for Ruby are probably wrong. I reused my code from other languages (with few changes) so it should be good. However, I'm getting these messeges:

L
L L
L   L
L L L L

should be
L
L L
L    L
L L L L

and only after I added in my code those methods:

def sierpinsky(n, preserve = false)
  sierpinski n, preserve
end

def mySierpinsky(n, preserve = false)
  sierpinski n, preserve
end

because earlier the test runner was showing me those messages:

L
L L
L   L
L L L L

should be
 `block in 
': undefined method `mySierpinsky' for main:Object (NoMethodError)
	from `each'
	from  `
'

I think there’s absolutely no need to depend on such micro-benchmarks. The real bottlenecks are somewhere else. However, each of these conversion methods has its own caveats:

• v.toString() — works well, unless v.toString is not a function, that is when v is null or undefined or when .toString was deliberately changed or deleted (very rare case)
• '' + v — works with nulls and undefineds too, but might give some unexpected results for such objects as:

v = {
  valueOf: function () { return 5 },
  toString: function () { return 'foo' }
}

in which case '' + v would return '5' (very rare case)

• String(v) — works every time, correctly calls .toString method, if an object has one, and works for nulls and undefineds
• '' + [v] or [v].join() — same as String(v) (unless you modified Array.prototype), with exception of nulls and undefineds becoming empty strings, which can be quite usefull sometimes

In the real world, it’s fine to use any of these methods, with caution while using v.toString() when v could be null and undefined. Choose, what’s most convenient/legible/usefull for you and your team. Performance differences are highly negligible.

You are right, I should have posted some explanation or a link to some article.

You see, many times I have seen people using parseInt (passing only first argument) as a way to convert strings to numbers, many of them didn't know about Number or unary +. In my experience, people who cautiously put , 10) at the end of parseInt tend to also know about other converting methods and their consequences, but of course it is not the rule.

The intention of my post was to point at other, possibly better way for converting strings to numbers. But you are right, I should have put some explanation to it.

For other readers:
Other conversation on that topic
②ality: “parseInt() doesn’t always correctly convert to integer”
Comparison of different methods of converting strings to numbers, a comprehensive list of test cases

Personally, for converting strings to numbers most of the time I use unary +, because of a short syntax (I don’t care about keystrokes, but I do case about screen space), also because of gracefully failing to 0 for cases like '' or null, which I find more practical than NaN. Last but not least, because of its predictability, values are treated just like those written in code. It’s, in my opinion, the least quirky way of convertion.

However there are some cases, where parseFloat is more useful than unary + or Number. For instance when converting CSS values to numbers, like 123px, parseFloat will give you meaningful 123, unlike Number’s NaN.
In case of parseInt, I use it explicitly for number conversion in different bases.

Remember that Number uses internal ToNumber function, which is also used in other places, like operator coersion (x * 1, unary +) or in Math functions. parseInt and parseFloat are using their own algorithms, so be careful.

Here is seemingly complete table of test cases showing behavior of parseInt, parseFloat, Number, +x and ~~x, might be useful: http://stackoverflow.com/a/17106702/409149

If you care about explicity, you can use Number() wrapper. It works just like the unary +.
Very often I see people using parseInt as a tool for converting numbers stored as strings to proper number type, in which case Number or unary + should be used (unless you know, what you are doing). Moreover, Number can sometimes be safer to use, e.g.:

['10', '10', '10'].map(Number); // => [10, 10, 10]
['10', '10', '10'].map(parseInt); // => [10, NaN, 2]

Also please check out http://www.2ality.com/2013/01/parseint.html .

Don't use parseInt for simple conversions from string to number, especially without providing radix argument. Use unary + instead.