-
Notifications
You must be signed in to change notification settings - Fork 0
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
reductions: add note about FP associativity #16
Conversation
If we'd like to indicate this change is an erratum, that PR is now updated here: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the API note, the proposal is going to be silent on statements like the following
- that the result should be the same on all PEs
- that the result should be the same if the operation is called multiple times on the same data during the same run
- that the result should be the same from run to run
- that the result may be different on different architectures, due to differing arithmetic
- that the result on IEEE-754 compatible platforms should always be the same everywhere and everywhen
- that we might consider new APIs or environment variables that enforce more consistent results
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a nice summary of the open issues. Can you capture it on the follow-up issue for OpenSHMEM 1.7 (and create said issue if we don't have one already)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Co-authored-by: James Dinan <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for preparing this! I made a couple small suggestions, but I think this is the right change to incorporate in 1.6. And you've already made great progress toward clarifications for 1.7.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok fine
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Summary of changes
Regarding this issue:
https://github.com/orgs/openshmem-org/projects/5/views/1?pane=issue&itemId=74045800
The WG decided to defer something like PR #14, which adds the requirements regarding the reproducibilty of OpenSHMEM reductions on floating-point datatypes.
This PR briefly explains the issue in an API note, and says a future version of the specification may clarify the behavior of reductions on floating-point datatypes.
Proposal Checklist