Rename split_off to split_off_left (as discussed in PR #189)

[schuster]

No description provided.

[nikomatsakis]

Thoughts?

[nikomatsakis]

Hmm, pre-existing, but I wonder if here it would be better to do:

let reducer = consumer.to_reducer();
let a = self.a.drive_unindexed(consumer.split_off_left());
let b = self.b.drive_unindexed(consumer);
reducer.reduce(a, b);

Seems like it would avoid an unnecessary split, which is better for the find_first code

[schuster]

Agreed, I'll push that change.

[nikomatsakis]

LGTM!

[bluss]

ndarray will attempt to use UnindexedProducer/this in a way where there is no ordering, I hope that it can be supported in some way? (Either split is not before/after the other) ascii art

[cuviper]

@bluss That's... challenging. I guess find_first and find_last don't make sense in that context?

[cuviper]

Perhaps those need to be in an OrderedParallelIterator, which ndarray would not implement. Then we may need an unordered split_off still, as opposed to this split_off_left.

[bluss]

In theory ndarray could offer a regular old iterator called .unorder_iter() which has no guaranteed element order (just whatever order is quicker to iterate). In the sense of defining the parallel iterator over that sequence, I think it's fine. Just like how the sequential version of find_first (Iterator::find) works fine on a hashmap iterator.

[nikomatsakis]

@bluss I'm not sure I quite follow, but it feels like that can be modeled "locally" as saying that the order of items from matrix iterators is not defined (much like the order of hashmap's iterator is not defined). This sort of implies that find_first is not meaningful, but it'll do something. Is there a problem with that?

[nikomatsakis]

In other words, I'm not sure we need to surface this distinction in the traits, though I agree we could.

[cuviper]

Maybe that's worth a note in the find_first docs, that not all iterators are ordered usefully.

[bluss]

The correspondence to arbitrary order sequential iterators clears it up nicely I think.