I hope you are happy.
Do have a look at the source code. Oh, and try turning up your speakers and typing in the Konami code...
A few suggestions, then:
1. Don't use i as the name of the parameter. A lot of people use that as the name of loop variables, and it means breaking habit or wasting time changing the name.
2. For test 3, try some multiple-extension files to make sure they did it right (some.file.multiple.extensions, should return "extensions")
3. For test 5, it says "integers". Try some non-integers during testing, to make sure that it's only checking for integers.
4. For test 5, it says "arrays". Try some objects to make sure they're not being lazy and using typeof thing === "object"
Anyway, thanks for making this. I love it!
30% figuring out the answer, 20% not having my editor shortcuts available, 50% figuring out how to check if a value is a certain type.
Am I the only one that gives their functions preconditions that the input is good? To me, throwing up when you're passed a non-number to a sum method is correct behavior.
I've confirmed that I can, in fact, code under pressure, but to what degree?
Other than that, fantastically fun game. My only regret is that it's a one-time game by nature, since obviously the second time around you'd simply be remembering what you did the first time instead of creating it.
https://twitter.com/search?q=I%20completed%20%22You%20Can't%...
n===+n && n===(n|0)
Wish I could see my answers after the fact though!Edit: Read the initial requirements of the puzzle, it says sum all the integers, not all the numbers. People using (typeof i[x] == 'number') just got lucky because the test-cases didn't exercise the full requirements of the puzzle ;)
// i will be an array, containing integers and/or arrays like itself.
// Sum all the integers you find, anywhere in the nest of arrays. sum += i[p];
}else if(typeof i[p] === typeof [3]){//it's an array recursion(i[p]);
}pretty simple no?
I dread to think what obscure code I've left behind.
You should learn a little more about JS before you call this simple.
n % 1 == 0It didn't actually require differentiating between integers and floats, just numbers and other types.
Normally javascript function inputs aren't this messy.
I finished this in 4 minutes.
Edit: looks like HN doesn't like asterisks
return input.split(".")[1] || "";
Absolutely! Being under the gun led me, at one point, to have a "longest string in array" method with a statement like
if (i[z].length < qq) { ... }file called .htaccess is not filename "" and extension "htaccess" with a "." separating the two. .htaccess is a unix style dotfile. its whole name is ".htaccess" and it has no file extension.
return i.reduce(function(prev, next) {
if (typeof(next) == "object" && next.length) { return arraySum(next) + prev; }
if (typeof(next) == "number") { return next + prev; }
return prev;
}, 0);
Something that simple needs to be shimmed on earlier IEs. In fact, I had to look up Array.prototype.reduce for this since I usually use Underscore's. Javascript problems...The bonus upside is that these paradigms also make parallelism quite simple, should it later be necessary.
function arraySum(i) {
var total = 0
for(var x=0; x < i.length; x++) {
if(typeof i[x] == 'object') {
arraySum(i[x])
} else if(typeof i[x] == 'number') {
total += i[x]
}
}
return total
}That was also my final answer. However, I was going for speed and not elegance, after looking at other people's responses with prototypes and all.
function arraySum(i) { var total = 0 for(var x=0; x < i.length; x++) { if(typeof i[x] == 'object') { total += arraySum(i[x]) } else if(typeof i[x] == 'number') { total += i[x] } } return total }
or am i missing something?
> typeof ["a", "b"]
"object"
Of course, since you're told you'll only get numbers, arrays, and strings, that is enough to solve the problem narrowly.I used i.forEach for questions involving arrays, instead of for-loops. Saves me time.
its like returning error codes in C for errors
Spent nearly the entire time on #3 because I was trying to use String.replace to work and failing. Ended up using .split instead, which passed thanks to poor test coverage (just like at work!).
For the "is this actually a string?" check, for example, I started looking for the existence of the match method on the object, which of course would have failed if they passed some random object with match defined so I cheated a bit. I'd like to see the full breadth of test options people took out there.
I wanna see one of these in Python.
Blew through the first 4 but spent half my time on the last one because I don't have Javascript type checking memorized.
The "kill screen" song is stuck in my head now.