Transform Iterators and Sort By Key

[neoblizz]

I have a use-case for performing a sort by key, where I don't actually care about the key but I'd like to use it to sort the values.
The problem here is that the keys are not stored anywhere, and I would like them to be "generated" using a transform iterator.
So, if I effectively passed the variance lambda into sort_by_key with a transform_iterator, I would get the input sorted based on the return values of the lambda.

auto variance = [=] __device__(std::size_t i) {
    auto x = input_data[i];
    return get_variance(x); // assume this returns an integer.
};

thrust::sort_by_key(
    thrust::cuda::par_nosync.on(stream);
    thrust::make_transform_iterator(
        thrust::make_counting_iterator<std::size_t>(0), variance),                   // keys begin.
    thrust::make_transform_iterator(
        thrust::make_counting_iterator<std::size_t>(num_elements), variance),        // keys end.
    input.begin());                                                                  // values begin.

But it seems like this use is not supported due to:

RandomAccessIterator1 is a model of Random Access Iterator, RandomAccessIterator1 is mutable.

Is my understanding correct? If so, any suggestions on another way to address this problem without actually first generating the keys and storing them separately?

[pauleonix]

You could do a thrust::sort and put the variance calculation into the comparison functor.

[neoblizz]

You could do a thrust::sort and put the variance calculation into the comparison functor.

Oh! Good idea, I'll give that a shot. Thank you!

[neoblizz]

Actually, I don't think that solves my problem. It needs to be a sort_by_key, where the key is based on the functor but the actual values you're sorting are stored somewhere else. Comparison functor would just cause you to either compare the values (which I don't want; and you cannot "figure" out the keys from just the values alone) or the keys (which is what I want, but then you cannot tell sort to sort the values and not the keys since it only returns a boolean).

[pauleonix]

So input_data and input are not the same? Couldn't you still use a zip_iterator with a counting_iterator to add indices to the elements? The input_data iterator could then be a member variable of the comparison functor. Or does this run into the same problem as the sort_by_key?