Consider Thrust Numeric library
maximum & minimum & absolute_value et al don't belong in thrust/functional.h but they are useful because algorithms can't take fcn ptrs yet
Thrust vectors should always fire constructors but a vector of numeric types shouldn't for performance reasons - numeric_vector needn't
Thrust should have mathematical vector types that actually work with extra goodness like a tuple interface
valarray is < because it doesn't do fusion, but it would be trivial to get something even better with a numeric_range template with math ops defined for it
All this stuff could go into a numeric sub-library
If we make vector more conforming [1], we ought to be able to enable users to implement uninitialized vectors themselves.
As a side effect, cusp data structures won't need to unsafely implement themselves via thrust::detail::vector_base.
[1] http://stackoverflow.com/questions/7218574/avoiding-default-construction-of-elements-in-standard-containers
Forwarded from http://code.google.com/p/thrust/issues/detail?id=216