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.

Sign up for GitHub

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

Jump to bottom

clarify the required accuracy for OpFMod and OpFRem #871

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

clarify the required accuracy for OpFMod and OpFRem #871

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions OpenCL_Env.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -28,6 +28,11 @@ include::config/opencl.asciidoc[]
// Formatting and links for API functions and enums.
include::env/dictionary.asciidoc[]

// External Footnotes
include::env/footnotes.asciidoc[]

<<<

include::copyrights.txt[]

<<<
Expand Down
16 changes: 16 additions & 0 deletions env/footnotes.asciidoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
// Copyright 2023 The Khronos Group. This work is licensed under a
// Creative Commons Attribution 4.0 International License; see
// http://creativecommons.org/licenses/by/4.0/

// Please keep footnotes in alphabetical order!

// Note: Follows the suggested syntax from:
// https://github.com/asciidoctor/asciidoctor-pdf/issues/1397

:fn-opfrem-opfmod: pass:n[ \
The *OpFRem* and *OpFMod* instructions use cheap approximations of remainder, and the error can be large due to the discontinuity in *trunc*() and *floor*(). This can produce mathematically unexpected results in some cases, such as *OpFMod*(x,x) computing x rather than 0, and can also cause the result to have a different sign than the infinitely precise result. \
]

:fn-type-min: pass:n[ \
Here `TYPE_MIN` and `TYPE_MIN_EXP` should be substituted by constants appropriate to the floating-point type under consideration, such as `FLT_MIN` and `FLT_MIN_EXP` for float. \
]
14 changes: 11 additions & 3 deletions env/numerical_compliance.asciidoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -198,6 +198,16 @@ devices given as ULP values.
| \<= 2.5 ulp
| Correctly rounded

| *OpFRem*(x, y)
| Derived from x - y * *trunc*(x/y) footnote:opfrem-opfmod[{fn-opfrem-opfmod}]
| Derived from x - y * *trunc*(x/y) footnote:opfrem-opfmod[]
| Derived from x - y * *trunc*(x/y) footnote:opfrem-opfmod[]

| *OpFMod*(x, y)
| Derived from x - y * *floor*(x/y) footnote:opfrem-opfmod[]
| Derived from x - y * *floor*(x/y) footnote:opfrem-opfmod[]
| Derived from x - y * *floor*(x/y) footnote:opfrem-opfmod[]

| *OpExtInst* *acos*
| \<= 4 ulp
| \<= 4 ulp
Expand Down Expand Up @@ -1782,6 +1792,4 @@ representable numbers in the range 0 < x < TYPE_MIN and -TYPE_MIN < x < -0.
They do not include {plusmn}0.
A non-zero number is said to be sub-normal before rounding if, after
normalization, its radix-2 exponent is less than (TYPE_MIN_EXP - 1).
footnote:[Here `TYPE_MIN` and `TYPE_MIN_EXP` should be substituted by
constants appropriate to the floating-point type under consideration, such
as `FLT_MIN` and `FLT_MIN_EXP` for float.]
footnote:[{fn-type-min}]