Michael Schellenberger Costa

Add a `synchronous_buffer` to cudax

4

We currently only have an `async_buffer`. However, that requires async resources and a lot of resources out there arent async. There are also a ton of use cases where using...

Use a more efficient `enable_if_t` implementation

2

This optimizes our `enable_if_t` implementation, which is one of the most commonly used types in the whole repository Rather than instantiating a type for every occurence we instantiate the type...

By default remove canonicalization of denormals in complex multiplication / division

4

But also adhere to the C standard wrt to infinities Fixes #1000

Replace `thrust::tuple` with `cuda::std::tuple`

2

The latter is more or less deprecated and we want to move towards standard types While we are at it also clean up the pattern of `make_zip_iterator(make_tuple(...))`

Replace `Thrust` sequential algorithms with `libcu++` ones

3

This might be a bit controversial because CCCL currently does not officially expose std::algorithms On the other hand it lets us replace a ton of thrust algorithms that are much...

I have a PR open that properly implements `fmod` and `modf` for all supported floating point types. However, that creates an ambigouity with the `fmod` definition in scalar_ops, because the...

Replace `Thrust` iterator facilities with `libcu++` ones

1

They are effectively the same and we should use the standard ones

Implement CUDA backend for parallel `cuda::std::for_each`

23

This provides a design for a dispatch layer for parallel algorithms in libcu++ We leverage the enumeration that is stored within the execution policies to determine the user-choosen backend and...

Implement `ranges::drop_view`

13

This implements `ranges::drop_view` as specified [here](https://www.en.cppreference.com/w/cpp/ranges/drop_view.html)

Replace internal uses of `thrust::tuple` with `cuda::std::tuple`

1

Its an alias anyway and we should be explicit in our uses internally