@Xavier Thanks. Glad you liked it. You can search the site for dynP function of Mr.Wizard, which has comparable performance to Internal`PartitionRagged, while being implemented purely in top-level code.

@ciao Thanks. It does work with negative numbers, for me. Can you provide an example where it fails for you? Re: slowdown - indeed. Probably related to the auto-compilation, although I still don't understand why - by default the arguments of compiled function are anyway reals.

@ciao One guess would be that, for integers, the list of 4 elements produced at each iteration of Fold, can still be packed, and is packed since Fold auto-compiles. For reals, the list contains 2 integers and 2 reals, and so can't be packed. Not sure if I am right, but I can't see any better explanation at the moment. One thing that kind of confirms my guess is that if you use N@{0, 0, 0, 0} as a starting value in FoldList, instead of {0, 0, 0, 0}, then the performance on integers also degrades just like it does for reals.

@LeonidShifrin: Range[-3,3] trivial example - s/b 7 distinct sets, but output is just the range...

@ciao This is not an error per se. The initial value of the sum, which the sum of elements in the first sublist of the result must be larger than, has not been specified by the OP. I took it to be zero. In this interpretation, the answer is right. Alternatative interpretation is that it it e.g. -Infinity (or, simply, any number smaller than the first element). The problem is simply underspecified in this respect.

@LeonidShifrin: Fair enough (depends on the what definition of "is" is, eh? ;-} ) - btw -cool way to do this for large lists is via bin search - quite fast...

@ciao You got me intrigued - how would you apply a binary search to this problem?

@LeonidShifrin: Shall I spoil the ending, or do you want the "ah-ha!" yourself? Hint: Look at the pattern of positions in the accumulation of the target list vs where the subset breaks happen...

@ciao As much as I'd like to solve this puzzle, I can't afford taking any more time from other things I need to take care of, at the moment. I did actually look at the accumulated original list before asking you, but I guess my pattern-recognition skills got seriously worse in the few last years. But the one thing that really stopped me from looking in that direction initially was that we can't exclude negative elements in the list, in which case accumulated list will not be necessarily sorted, and so binary search can't be used. But I see the direction of thought.

@ciao Ok, I am here

Since the subsets rapidly grow to non-single elements, this avoids traversing the list sequentially, and a quick cobbled-up test showed it much faster for large cases...

The last part I sort of anticipated, yes

Anyway, semi-interesting problem, but pretty clear large cases / performance does not matter to OP , since accepted answer gets agonizingly slow for such things compared to other simpler answers posted. Thanks for interchange!

@ciao This is pretty non-obvious. I guess I am losing my touch :) (assuming I ever had it). I still don't understand why having negative elements is a non-issue though: how can you use binary search if you list on which you search isn't sorted?

@ciao And that won't change if you add any constant to the entire list, if that's what you meant by lifting a list

@ciao B.t.w., I agree with you in that I am also puzzled by why the OP picked that answer as accepted - it doesn't strike me as either too simple / elegant or fast, when compared to other answers.

@ciao Anyway, thanks for the discussion!