inplace_merge, nWayUnion

[bearophile]

Andrei:

Sorry for my late answer, yesterday I was very busy.


>What I was saying is that in a past bug report you complained that find() is too hard to understand.<

An in a later post I have explained what in my opinion it can be done to improve the situation (this is not a fully good answer, but it gives a good idea of what I was thinking):
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=113555


>That was because find() supported things like heterogeneous ranges and finding more things than one in a single-pass manner.<

The main problem of find() is in what it returns, not in what it takes as arguments.


>Making nWayUnion accept heterogeneous ranges would no doubt increase its implementation complexity - probably worth it given the increased leverage.<

My idea probably will make it more complex internally. But it's library code, so what's more important is how complex its usage is, not its internal complexity.

I have had to use nWayUnion three times so far, and in two times I was in need to perform a 2-way or 3-way merge of lazy iterables, and I have had troubles in using nWayUnion, so much that I have written my own merge. So I think currently nWayUnion is not so useful because it is too much limited.


>All I'm saying is, please remember that solutions that are at the same time simpler and more general are in short supply.<

"simpler" means many different things. Your library code may be simple to use and to understand and yet be complex internally. The point of a library of algorithms is to make user code shorter and clean and efficient. I agree that designing a good library is a job of balancing some opposed needs, but this is not my fault, it's the nature of the game :-)


If you don't want to modify nWayUnion(), there is another solution, to not modify nWayUnion and to create an adaptor:

nWayUnion(Sequence(r1, r2, r3))

Sequence() takes as arguments one or more iterables, it's like a Tuple and it supports random access with [], but its template constraint assures that all the given iterables yield the same type:

Sequence(iota(10), [20, 30])  this is OK.

Sequence(iota(10), [20.5, 30.5])  this is not OK.

So:
Sequence(r1, r2, r3)[0].front() returns what r1.front() returns.


I don't know if this is a good idea. I prefer the simpler syntax nWayUnion(r1, r2, ...)

Bye,
bearophile