Skip to content

1/n: conforming parallel range algos to the standard#6945

Open
sleepingeight wants to merge 1 commit intoTheHPXProject:masterfrom
sleepingeight:parallel-0
Open

1/n: conforming parallel range algos to the standard#6945
sleepingeight wants to merge 1 commit intoTheHPXProject:masterfrom
sleepingeight:parallel-0

Conversation

@sleepingeight
Copy link
Copy Markdown
Contributor

Prototyping implementation for aligning parallel range algos to the standard.

Signed-off-by: sleepingeight <theallrounder.mst@gmail.com>
@StellarBot
Copy link
Copy Markdown

Can one of the admins verify this patch?

@sleepingeight
Copy link
Copy Markdown
Contributor Author

@hkaiser, I think similar changes are required in the area of parallel algos (modernising the implementation). So, I was thinking to deal with the documentation seperately (maybe as a community effort to speed things up since I've seen many mistakes in the documentation). So, I'm thinking to work in this order -

  1. Conform parallel range algos to the standard (I'll do this entirely)
  2. Modernise parallel algos similar to the adjacent_difference (which you've done previously)
  3. Update documentation overall.
    (I can create issues for 2 and 3 so that work is done in parallel and is also not a big task and works very well as good first issues)

@sleepingeight
Copy link
Copy Markdown
Contributor Author

@hkaiser PTAL at this PR. Thanks!!

@hkaiser
Copy link
Copy Markdown
Contributor

hkaiser commented Feb 27, 2026

@hkaiser, I think similar changes are required in the area of parallel algos (modernising the implementation). So, I was thinking to deal with the documentation seperately (maybe as a community effort to speed things up since I've seen many mistakes in the documentation). So, I'm thinking to work in this order -

  1. Conform parallel range algos to the standard (I'll do this entirely)
  2. Modernise parallel algos similar to the adjacent_difference (which you've done previously)
  3. Update documentation overall.
    (I can create issues for 2 and 3 so that work is done in parallel and is also not a big task and works very well as good first issues)

This sounds good. Just please remember that in order for somebody to be able to review changes, the PRs can't be too large. Thus I'd suggest to keep the change sets small and rather have a larger aount of PRs that are manageable.

@hkaiser
Copy link
Copy Markdown
Contributor

hkaiser commented Feb 27, 2026

Also, there is still the issue described here: #6718, with an attempted solution here: #6843. All of this will require touching on all algorithm APIs in any case, thus I'd like to think that we first should decide how to resolve the issues before investing time to update things that might have to be changed again afterwards. Please note that I don't have a solution for this yet, so this will require a bit of experimentation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants