Changing the return statement to explicitly build the dictionary makes the method clearer and more obvious as to what is going on. That, and the range(1, 7, 2) bit are the only parts that threw me.

Beyond those... I'm actually kind of annoyed at you for how perfect your solution is!

This has now been changed. Thanks again for the suggestion! Let me know if there's any other issues you see.

Thanks for the suggestion! It also doesn't help that the original formatting used in the description is broken as well. I'll take a look at getting it fixed up again.

As usual, that happens when you modify the input array.

I just fiddled with your code a bit and the array is changed after running your function.

@Shivo, you were great at explaining this to a number of people.

You've said multiple times that this problem is intended for beginners.

@sabrick, who is 7 kyu and so by definition is a beginner... I'm not sure how your response could be considered anything but offensive, especially as you've responded much more kindly to all the others who have had similar issues as this.

Someone not strong in English looks up the definition of the word sum in a dictionary and get precisely what @sabrick pointed out. At least in the closest dictionary I have:

noun

1. a particular amount of money: they could not afford such a sum.
2. (the sum of) the total amount resulting from the addition of two or more numbers, amounts, or items: the sum of two prime numbers.
   ...

verb

find the sum of (two or more amounts)...

So given that, it seems a pretty reasonable point to bring up.

It seems I and a number of other people have stumbled on the idea that index of zero, or the final element, could ever be the solution. While you do have, at the end of the problem description verbage implying that these indices are considered valid:

An empty array should be treated like a 0 in this problem.

the confusion and problem still stands as a number of people are tripping up on this.

As you said in a response to DSchwettmann:

... this was designed with beginners in mind.

You've also said similar in other places. As this is designed for beginners, the problem description should, I would think, make the entire scenario obvious and explicit.

As was noted also, http://www.codewars.com/kata/midpoint-sum is nearly identical to this, although yours does have many qualities which make it better, however it explicitly states that

Both the first and last index cannot be considered as a "midpoint"

For taylorn16 you specifically noted:

So to reiterate:

You are given the array {20,10,-80,10,10,15,35}

At index 0 the left side is {}

The right side is {10,-80,10,10,15,35}

They both are equal to 0 when added.

Index 0 is the place where the left side and right side are equal.

While perhaps a bit verbose, if this example were in the problem description it would help clarify the scenario greatly. Given that this is designed for beginners, explicitly stating this in the problem description rather than merely implying it with the comment to treat empty arrays as equal to zero would help both beginners and more experienced programmers understand the problem more accurately.

Reading through the discourse, I found these people with comments indicating that they stumbled on this precise issue, though worded differently, of course: sabrick, kylin60, Mosaaleb, mk03602, rephrehensible, nonrubyprogrammer, taylorn16. There may be others who haven't spoken up about it, as well.

I think this solution also is O(n²) and as noted by others, an O(n) solution exists.

@snake2

Assume that there is no match for the midpoint, so you'd return -1.

arr.each_index do |i| will iterate n times (where n is the length of arr).
Inside each iteration, the reduce call is itself iterating m times (0...i) and l times (i+1..-1) [l + m = n - 1, though, which is effectively n].
So you are doing n times n (or n²) iterations, so you have a function that costs O(n²) to run.

This can be solved with a cost of O(n). Someone smarter than me might have one even better. Maybe.

It is similarly not made clear that there will be non-alpha entitities (punctuation). That significantly alters things so that some approaches make much less sense.

If the number is negative, it is not a prime by definition. Using the absolute value would result in incorrect responses.

Sorting the array is a very inefficient way of solving the problem. Folks in the comments pointed out that sorting takes O(n log n) time. The better solution takes O(n) time.

You are correct. names.sort! will modify the original list, which is probably not what is desired by this method.