ensure that partition + zip_iterator works

[GoogleCodeExporter]

We don't seem to have a unit test for this case

Original issue reported on code.google.com by jaredhoberock on 14 Jul 2010 at 7:09

[GoogleCodeExporter]

All the rearrangement functions should be written in terms of copy_if() (this 
needs to be verified), so testing copy_if() ought to be sufficient for now.  
When we switch to the new testing framework we can test zip_iterator x 
algorithm more easily.

Original comment by wnbell on 16 Jul 2010 at 9:39

[GoogleCodeExporter]

Hi,

I think stable_partition + zip_iterator may be broken since when I try to do 
something like

thrust::stable_partition(thrust::make_zip_iterator(thrust::make_tuple(kD.begin()
,eD.begin())),thrust::make_zip_iterator(thrust::make_tuple(kD.end(),eD.end())),E
lementFreeBoundPartitonPredicate<1>());

where kD and eD are host_vectors gcc 4.3.4 gives me

/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/include/g++-v4/bits/stl_algo.h(1337): 
error: no instance of overloaded function "std::__rotate" matches the argument 
list

The same code using device_vectors works just fine. Is there a quick fix I can 
apply to this problem? Unit test for this issue should also be very helpful.

Original comment by janick.m...@gmail.com on 27 Jul 2010 at 10:51

[GoogleCodeExporter]

Original comment by wnbell on 28 Jul 2010 at 1:00

• Changed title: ensure that partition + zip_iterator works
• Changed state: Started
• Added labels: Milestone-Release1.3, Type-Defect
• Removed labels: Milestone-Release1.x, Type-Enhancement

[GoogleCodeExporter]

This issue was closed by revision b00805e4f4.

Original comment by wnbell on 28 Jul 2010 at 1:29

• Changed state: Fixed

[GoogleCodeExporter]

Janick, please confirm whether revision b00805e4f4bd fixed the problem.

Original comment by wnbell on 28 Jul 2010 at 1:30

[GoogleCodeExporter]

This issue related to CPU stable_partition is working with the main git branch 
now, thanks.

However, until now I used the 1.2.1 version. Now with the current development 
version I have a lot errors related to thrust::copy() like the following:

thrust::copy(coords, coords + 3 * numVerts, y.begin());

where coords is a float* and y is a std::vector<float>.
the error looks like this:

thrust/detail/host/dispatch/copy.h(60): error: no suitable constructor exists 
to convert from "float *" to "__gnu_cxx::__normal_iterator<float *, 
std::vector<float, std::allocator<float>>>" .

Was there something severe changed in the meanwhile related to the copy 
function? The code used to work before... Maybe I should open a new bug for 
this then?

Original comment by janick.m...@gmail.com on 28 Jul 2010 at 7:43

[GoogleCodeExporter]

Another related issue might be the error of compiling

thrust::scatter(mx.begin(), mx.end(), mapping_roi_local_globalD.begin(), ptr + 
offset);

with mx and mapping_roi_local_globalD beeing a device_vector's and ptr is an 
"ordinary" host pointer on ValueType which I think is a model of 
RandomAccessIterator.

The full error is in the attached file. The same code compiles if ptr is a 
thrust::device_ptr<ValueType>.

Another related problem is the compilation of

thrust::scatter(thrust::make_constant_iterator(resetvalue), 
thrust::make_constant_iterator(resetvalue) + unusedD.size(), unusedD.begin(), 
ptr + offset);

where unusedD is again a device vector and ptr an ordinary vector. The error in 
this case boils down to

/opt/cuda/bin/../include/thrust/iterator/detail/minimum_space.h(86): error: 
incomplete type is not allowed
          detected during:
            instantiation of class "thrust::detail::minimum_space_impl<false, false>::apply<T1, T2> [with T1=thrust::host_space_tag, T2=thrust::detail::cuda_device_space_tag]"

I attached the full error trace in the log file.

What am I missing here? Is is not possible any more to use ordinary host 
pointers as Iterators in the thrust algorithms?

Original comment by janick.m...@gmail.com on 28 Jul 2010 at 8:14

Attachments:

• errors.txt