How come when implementing merge sort the mid doesn't need to deal with odd/even division?

I know int will always go down if there is decimal but how will it cover the whole array?

Full code:
https://gist.github.com/allanx2000/...

I guess in general, array indexing that involves dynamic cutoffs always confuse me.

How do you think about them without having to try things out on paper?

Forgot to attach picture of the picture

And forgot to include the actual problem. https://hackerrank.com/challenges/...

The lines 4 and 5 in that method adjust the appropriate indices and run recursively. "mid + 1" is the clue here

@asgs so that would mean the end parameter is inclusive. Otherwise it would be skipping mid?

Now I see the for (int i=0; i< (mid-low+1);i++)

What's looking for a <= so basically this would mean the Left side will always have the 1 more item than the right if and odd succeed array is the input?

Guess is the "indexes start at 0" thing that makes it tricky...

@asgs but how do you instinctively think like this. I guess this is why I hate sorting, tree arrays so much.

I can never figure out the indexing calculation quickly

@billgates it just takes more and more practice.

More importantly, you need to rubberduck. Explain it with examples - simple ones - arrays of smaller sizes, odd and even both. It is called base case or something. Then you generalize it and write code like a Boss

@asgs rubber duck it's what I do but I can't seem to like I dunno... Google/FB devs? That can sorta go "isn't using I < mid-low+1) obvious"

Otherwise how the fck can they pass those tech interviews?