Check out a free preview of the full Complete Intro to Computer Science course

The "Merge Sort Q&A" Lesson is part of the full, Complete Intro to Computer Science course featured in this preview video. Here's what you'd learn in this lesson:

Brian answers student's questions regarding why left and right are being concatenated and what the policy for using built in JavaScript methods. Questions also covered in this segment include: if merge can be made recursive and if the solution could be completed in one function call.


Transcript from the "Merge Sort Q&A" Lesson

>> So the question is is on line 40? Here, why are we concatenating left and right? And the answer to that question is one of these is empty left and right, right? So, we just need to make sure that those results get concatenated onto the end of results so that we capture all those numbers, because we know everything that's in that's left in either left or right is by definition gonna be larger what's already in results, which is why we can just freely concatenate what's ever in there.

>> I just was wondering like what's, like the policy for using built in JavaScript functions? Like cuz I seen the other problems and stuff and different solutions where some use built in JavaScript methods like reverse shift here. And then others trying to find solutions that are just more basic.

Yes. Just wondering what, in your experience, what does that look like?
>> So I think the question is, in particular around push and shift here. And the question being like, what's our policy? What's the recommendation of when you can use shift and push and when should you drop into something lower and maybe do the direct manipulation yourself because the, yeah, this shift functionality could actually be quite inefficient in terms of how, it depends on how the array is implemented.

In this particular case, I just want you to learn. So if you understand that stuff is coming off the front, we could have done this with counters and said, and have two, four loops and an ion and a jade that's moving forward and that would have probably been more efficient in terms of not Jocelyn the arrays around.

That's fine. If you wanted to do that that makes sense. It probably will be more efficient. In this particular case, I just want you to learn how the algorithm works and I'm not interested in having the absolute most effective way of doing it. So it depends. Sorry, I apologize that that is the answer yet once again.

If you are extremely sensitive to performance, then these are things you have to worry about. If you're not, then I'd say this is more readable then trying to keep track of two counters.
>> Okay, that makes sense.
>> Yep, good question.
>> Yeah, I tried my hand in fighting the merge part of this thing and I recursive styles.

>> I guess yeah, I guess you could, instead of saying ,merge stuff goes here. Instead of having a merge function here, I guess that works, but I wouldn't do that.
>> That wasn't the thing like the merge function is separate in what I did but it's also it calls itself.

Merges it in little parts. I think there is a reason, is there a performance reason to prefer an iterative approach in merging?
>> I'd have to think about that, but I can't see this being any clear, right? The reason why you would wanna do this recursively is if you made the code look better, and like can read better.

But I don't know about you this I find this code quite readable. But it's obviously a point of opinion here. I would not make merge recursive, I can't think of a good reason to do that. You could, probably, I'd have to think about it. But I'll say this that typically merge is not made recursive.

But to answer the online question here, you could absolutely do this just move this up in here. And then this would just be sorted left. Sorted right? And then you would just return and then you'd have to do the return, concat, Yeah, all that stuff would just end up here.

And I think this should still work. What did I do? I hope this needs to be sorted left. There we go, and that works. So, the reason why I don't, [COUGH] excuse me. The reason why I don't like that is because I really liked having all this separated into one little merge function.

One, this is now usable in other places. Not that I think you would, but it would be. But more importantly, you can actually write unit tests individually for merge, right? So you can actually test this one piece of function in isolation by itself. And that's always a good thing.

As much as possible in general, just as a general programming rule, one function does one thing, as much as possible, right? Again, remember rule number one here is there are no rules. So if there's, if it makes sense to have a function do two things, then by all means do it.

In this case, I think it makes a lot of sense to separate this into two separate things.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now