It's one thing to understand the concept of time/space complexity. It's another to apply the knowledge when solving algorithm puzzles. After readin...
For further actions, you may consider blocking this person and/or reporting abuse
Hey just to point out that
shift
itself is a bit of a pain doing it frequently - that's because a shift "might" have to move all of the elements in the array (it's not allocating fortunately) - it depends on the actual engine implementation - but it's likely.push
andpop
are very fast operations because they only change the length of the array,unshift
andshift
have to move all of the items in the array (because the operate at the beginning). So depending on what you are doing it might be wise to reverse and array and operate at the end - really would have to be a lot of operations though.In the case of a
rotate
you can use the fact that.splice
returns the items it removes sorotateLeft
to me looks like:Effectively push on the end the items you removed from the front. The cost of this is an array the size of the items you removed. But no loop.
Thanks Mike for pointing out the potential costly operation of
shift
-- I read somewhere that also comparedshift
withpush
andpop
, but your explanation makes more sense to me. And yes, usingsplice
first and adding the specific items to the array via spread operator does look more efficient. Really appreciate your help! :)Yeah we can do it without spread - but now it looks nicer in ES6 :)
It looks like you could get better perf (at least for long arrays) using
Array#concat
without the spread operator:jsperf.com/concat-vs-spreader
Also remember that
Array#push
returns thepushed itemnew length of the array, not the array 😉You're right, should have a
, array
at the end I guess or a separate lineWhat's wrong with the obvious solution:
This is a straightforward O(n) solution.
Slice(), push() and all that are nice.. but won't a for loop do better in this case? (to avoid allocation issues)
Nothing wrong, it just wasn't on top of my head when I first approached the problem, especially applying the modulo operator, which was not an obvious/natural thought process for me. And somehow I didn't find that solution during my search. So thanks so much for sharing. Adding to my notes as we speak :)
Well, your proposed solution only shifts the elements one place, while the challenge was to create a function that shifts them an undetermined number of places.
just change:
let next = (i+1) % a.length
to
let next = (i+offset) % a.length
Where offset is the number of spaces you want to shift.
Your algorithm works for only 1 place shift, even with the edit you provided.
Hello, Annie!
It is not objective to compare how slice is used between the two solutions.
In your solution, you are copying almost the whole array (n-1) in every iteration. In the 10/10 solution the array is copied so that there are no side effects on the input parameter.
The shift operation is operating on the array, not copying, so there is your performance difference.
Ah, I see. Thanks for the crisp explainer, Valeri!
It's got to be that
slice
method, it's going to allocate a new array, and that's going to be really expensive. If you're allowed to modify the input, then you should be able to do it really fast by keeping track of two indexes, one to copy from and another to copy to. If performance is important, then it's probably wise to do it like this, as it's unclear how changing the size of the array will affect performance. As you noted, memory is allocated in chunks of a given size, so to change the size of the array, it may need to allocate new memory and copy it over. Could also vary across JS implementations, I'm not sure if the specification dictates this or not. Anyway, have a link to the problem? I want to try it now!Thanks Josh! Sure, here's the leftRotate challenge on HackerRank.
So I was a little bit wrong. Keeping track of two indexes doesn't work unless you also keep an array of the
d
items that will get overwritten. And then at that point, it's probably worse thanarr.push(arr.shift())
. However, because they verify the result by having you write it to a file, you can still optimize like I was thinking (basically, you don't have to rotate at all, you can just start printing the numbers from the offset, and then loop around to the beginning (I cleaned it up a bit, their template was really verbose which made it difficult to follow):It's not immediately clear that this will be more performant, but looking at the docs, it seems like it will be. If it were actually doing multiple file writes, then that would be expensive, and it might be better to rotate the array and join it into a single string to be written. But the docs say it should buffer the writes, so this is probably similar to what I had in mind. That said, I'm not confident it will be faster without benchmarking, as joining the array may avoid the allocation of the string with the space on the end of it.
Interesting. I always skipped the file writes and jumped to the function instructed. Not sure if this is what the challenge intended, but it's cool to see we can change input like that, as I'm still a NodeJS newbie. Thanks for taking a deep dive into this, Josh.
For rotating an array of length n by k places, the trick is to