Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[oneDPL][rfc][ranges] proposal for implementation of the second part of range based API for oneDPL #2037

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

MikeDvorskiy
Copy link
Contributor

[oneDPL][rfc][ranges] proposal for implementation of the second part of range based API for oneDPL

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please rename to range_algorithms/README.md

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

rfcs/proposed/ranges_api_m/README.md Outdated Show resolved Hide resolved
rfcs/proposed/ranges_api_m/README.md Outdated Show resolved Hide resolved
Comment on lines +13 to +14
- The range-based signatures for the mentioned API should correspond to the proposal for C++ parallel range algorithms, P3179.
(https://wg21.link/p3179)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As an exception to this rule, we might have mismatch to follow equal and transform in the oneDPL specification and allow only one of the two ranges to be sized.

I am still thinking of the best way to handle this.

### Key Requirements
- The range-based signatures for the mentioned API should correspond to the proposal for C++ parallel range algorithms, P3179.
(https://wg21.link/p3179)
- The proposed implementation should support all oneDPL execution policies: `seq`, `unseq`, `par`, `par_unseq` and `a device policy`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- The proposed implementation should support all oneDPL execution policies: `seq`, `unseq`, `par`, `par_unseq` and `a device policy`.
- The proposed implementation should support all oneDPL execution policies: `seq`, `unseq`, `par`, `par_unseq`, and `device_policy`.

Comment on lines +23 to +25
### Test coverage

- It should be called with both small and large data sizes and with all the policies mentioned above.
Copy link
Contributor

@akukanov akukanov Feb 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it make sense to also mention what kinds of input and output ranges (containers, views, etc.) will be tested?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants