Yustynn did a great job explaining what I meant.

I'm new to programming, but I think he's talking about having two iterators instead of one.

In the original solution, you had ruby run through each element one by one to filter out unwanted elements. Then you go through those selected elements one by one again to sum them up.

His solution does it all one shot. In his inject, he goes through the elements one by one but performs both actions (filtering and sumation) before moving on to the next element. Meaning that instead of running through all the elements twice (once to filter, once to sum), he does it once and he's done.

So worst case: all integer values. All elements are run through once, none are rejected. Then all have to be run through yet again to sum. Two run throughs instead of one, so supposedly 2x the time taken.

Could you explain further? I am trying to get my head around why it'll require twice as much computing in worst case.

100 % agree. We should not give away efficiency so easy.

I'm pretty jelly I didn't think of this one. Its faster, shorter and maybe more readable.

I like your functional approach although it doesn't feel idiomatic.

It would be great if either of you could post a comparison using the ruby benchmark module - It'd be interesting to see if Ruby optimizes the code, so that it performs better than the theoretical bound.

Excellent point. Your solution runs much faster on very large inputs.

Very good use of a 1 liner but I don't like it because you it'll run in worst case 2n time where you can do it in n time.