4 ms·
If the standard library includes a variant for these or any other functions, it's probably idiomatic to use them. They handle edge cases, are better optimized a
by rootlocus 6y ago
If the standard library includes a variant for these or any other functions, it's probably idiomatic to use them. They handle edge cases, are better optimized and they're explicit.
- jacobolus 6y agoThere is no way that any Javascript library function is "more optimized" than just using `n % 2`, which is also plenty descriptive. If this is very performance sensitive you can try using the somewhat more obscure (because many people have minimal experience with bitwise operators) `n & 1` instead. Given an integer input, thare are no "edge cases" to worry about here. If you expect floating point inputs, you need to think carefully about what the correct output should be anyway. A library isn’t going to save you. (If your "edge case" is that someone might want to know whether a string is even or odd... well, you have other problems.)
- d_watt 6y agoIt's funny, because in the case we're talking about, there appears to be edge case behavior if the number is a "safeInteger." While I agree in principle I would never import something as granular as "is-odd," just researching this specific package revealed an edge case someone ran into and solved, and you don't have to worry about as a dev if you take it off the shelf. https://github.com/jonschlinkert/is-odd/blob/master/index.js#L20 https://github.com/jonschlinkert/is-odd/blob/master/index.js...
- jacobolus 6y agoYour "isodd" function should probably not be doing bounds checking and throwing an error when it encounters large even integers. If you have a use case where you need to know if you multiplied two large integers and got a result larger than 2^53, then you should do it explicitly before you get to the point of checking if your number is even or odd.