Implement std.algorithm.cartesianProduct #856
Conversation
|
Yikes! Looks like the autotester is failing on issue 8556 (cf. 8790). :-( |
|
Fixed coding style, rebased. |
|
Quick comment - I think we should sleep on getting the infinite forward ranges implementation right; if we commit this the risk is to discourage more general implementations. The idea for merge on two infinite forward ranges is as follows. Imagine we show the ranges in a plane with r1 horizontally and r2 vertically. Then we first walk the square of side 1. There's only one: tuple(r1[0], r2[0]). Then we walk the square of side 2: (0, 1), (1, 0), and (1, 1). Then we walk the square of side 3: (0, 2), (1, 2), (2, 0), (2, 1), (2, 2). Note that how at each step one index is constant and the other either grows by exactly 1 or it gets reset to 0, thus making the algorithm implementable with forward ranges. The jump from the corner (1, 1) to (0, 2) is a bit special: one range is advanced and the other is reset. |
|
That's an excellent idea! So basically instead of diagonals, we alternate between vertical and horizontal line segments of increasing lengths, which meet at the diagonal. I'll think about how to implement this. |
| } | ||
| } | ||
|
|
||
| // vim:set sw=4 ts=4 expandtab: |
There was a problem hiding this comment.
Probably unrelated line. )
|
This is good work. I think it's important that we fix the elusive compiler bug to allow this and many other instances to work. cc @9rnsr |
|
Rebased and updated to Andrei's new schedule that only requires forward ranges for the two infinite ranges case. Unittests still do not compile due to the bugs as mentioned in the forum, but I thought I should at least put the code up for review first. |
|
Just for reference, here's the cause of the current autotester failures: |
|
Rebased to prevent from going stale. Since issue 8542 is still open, the autotester will probably still fail, though. :-( |
|
Is there anything you can do to workaround the bug? It would be nice to get this in if the bug is going to take a while to fix. |
|
Unfortunately I'd have to disable a lot of unittests for that to work. It might be possible to split up the unittests, though. I'll give it a shot when I get home (I'm travelling currently). |
|
Rebased, and rewrote unittests to avoid issue 8542. The original unittests are version'd out for future reference, in case we wish to run the old tests again after issue 8542 is fixed. |
|
Is std.algorithm getting too big for some of the autotester machines? |
For the case of two infinite ranges, use Andrei's schedule of traversing right and bottom edges of an increasing square area over the infinite table of combinations. This allows us to only need to traverse each range in one direction, so only forward ranges are needed.
Make unittests independent of exact order of pairs produced by cartesianProduct. Add unittest for cartesian product of two finite ranges.
|
Rebased to fix merge conflict. |
|
Looks like we're good to go! Any tests on composing |
|
I'll merge this now anyhow, we can think of adding variadics later. |
Implement std.algorithm.cartesianProduct
As discussed in the forum. This implementation supports infinite ranges as long as they satisfy certain range requirements.