groupBy predicates: unary, binary, or both?

monarch_dodra monarchdodra at gmail.com
Sun Dec 29 02:20:20 PST 2013


There is precedence for this in phobos with schwatzSort: It use a 
unaryFun, followed by a binaryFun.

I've found this works quite well: More often than not, a unary 
fun is more than enough (the default "a < b"/"a == b" is fine). 
And in the cases where you *do* need binary comparison, then 
having a unary fun anywas is fine. EG:

"MHklfsJKGsfd".byGroup!(std.uni.tolower, "a < b")();

I think it is both an elegant and efficient approach. That's what 
I'd go for.

-------

I think we should handle non-commutative predicates. It's not 
actually *that* much more complicated. Instead of storing in each 
Group a value + range, simply save the range twice, and have one 
range be 1 step ahead of the first. I think a few phobos algos do 
this. minPos does something kind of similar.

The "overhead" is an initial extra save yes, but the cost of each 
pop is to simply pop both ranges (no extra saves there). You 
never actually have to make element copies (which may fail if the 
range holds const elements to boot...). Also, if the ElementType 
is big, then storing an extra range has good chances to actually 
take up *less* room.

My stance is that supporting this would be a powerful and useful 
tool, and I don't think there'd be that much overhead either, so 
I say let's go for it.


More information about the Digitalmars-d mailing list