Yes! Using the prototype you only have one function that's shared by all the instances. If you define it inside the function, you're doing extra work and having multiple instances of that method in memory if you have multiple instances of the Person

Edit: so yes, it's faster and consumers less memory when you have multiple instances

Prototypes! This is how you originally did "methods" in JavaScript before there was classes. Classes are in fact just built on top of prototypes

Wonderful implementation of the zip function.

Clever one. With a couple of modifications you'd get a full brainf*k -> javascript compiler.

It would have been cool to compile it all to javascript and run a single eval() on the whole compiled source code :)

Looking more at the solutions, I think you should also check for valid edge cases with decimals:

"90.000, 180.000"
"-90.000, -180.000"

Since there are some solutions that just check for strings like 90 and 180 without the decimals

Great job, but should check for the minus sign before 90/180, since it now doesn't accept -90, -180 as valid coordinates

Also, as an addition to @Fake51 comment, you should test for the most edge cases for valid coordinates:

"90, 180"
"-90, -180"

Now there are some solutions that wouldn't pass those edge cases.

And thank you for a really refreshing and valuable kata! Loved this one!

I think you went quite deep with this... :D

The Number object in javascript is a 64-bit double-percision floating-point format.

What this means (in practice) is that the more closer the Number object's value gets to 0, the more percision it has.

To demonstrate this effect, you can try it out yourself:

0.0000000000000001 + 0.0000000000000001 = 0.0000000000000002 // <-- percision is enough near zero
1.0000000000000001 + 1.0000000000000001 = 2 // Not enough floating-point percision, so the number is rounded to nearest presentable number

Ok, so what this means is the further we go from 0, the less percision the floating point has.

The Number.MAX_SAFE_INTEGER is actually the biggest number you can type when the floating point percision is <= 1. So you can get to bigger numbers, but they have lower percisions than 1.

Let's try this out:

Number.MAX_SAFE_INTEGER - 1 = 9007199254740990 // <-- Enough percision
Number.MAX_SAFE_INTEGER + 2 = 9007199254740992 // <-- Percision gets lower than 1 (in this case, 2) so the value is rounded to nearest presentable number

Ok, but why did I mention that there are something called 32-bit integers in JS?

You basically can't do bitwise operations using a floating-point type number. So JS needs to have a separate integer number type.

So if you, for example, do something like:

var floating_number = 1.5;
console.log( floating_number | 0 ); // Will output 1, since JS transforms the float to int

So yes, JS does have 32-bit integers, while the default Number object type being a 64-bit double-percision floating point type number.

I suggest to read an excellent atricle from Josh Haberman called "What every computer programmer should know about floating point"
(http://blog.reverberate.org/2014/09/what-every-computer-programmer-should.html). It helped me to really understand how numbers work in various programming languages.

Would fail at add(3,1) :(

A good way to reduce the number of lines; though it doesn't throw errors and actually delete properties