+
+### function accuracy in standards (opencl, vulkan)
+
+[[resources]] for OpenCL and Vulkan
+
+Vulkan requires full ieee754 precision for all F/D instructions except for fdiv and fsqrt.
+
+<https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/chap40.html#spirvenv-precision-operation>
+
+Source is here:
+<https://github.com/KhronosGroup/Vulkan-Docs/blob/master/appendices/spirvenv.txt#L1172>
+
+OpenCL slightly different, suggest adding as an extra entry.
+
+<https://www.khronos.org/registry/OpenCL/specs/2.2/html/OpenCL_Env.html#relative-error-as-ulps>
+
+Link, finds version 2.1 of opencl environment specification, table 8.4.1 however needs checking if it is the same as the above, which has "SPIRV" in it and is 2.2 not 2.1
+
+https://www.google.com/search?q=opencl+environment+specification
+
+2.1 superceded by 2.2
+<https://github.com/KhronosGroup/OpenCL-Docs/blob/master/env/numerical_compliance.asciidoc>
+
+### Compliance
+
+Dan Petroski:
+
+ It’s a bit more complicated than that. Different FP
+ representations/algorithms have different quantization ranges, so you
+ can get more or less precise depending on how large the arguments are.
+
+ For instance, machine A can compute within ULP3 from 0 to 10000, but
+ ULP2 from 10000 upwards. Machine B can compute within ULP2 from 0 to
+ 6000, then ULP3 for 6000+. How do you design a compliance suite which
+ guarantees behavior across all fpaccs?
+
+and from Allen Baum:
+
+ In the example above, you'd need a ratified spec with the defined
+ ranges (possbily per range and per op) - and then implementations
+ would need to at least meet that spec (but could be more accurate)
+
+ so - not impossible, but a lot more work to write different kinds
+ of tests than standard IEEE compatible test would have.
+
+ And, by the way, if you want it to be a ratified spec, it needs a
+ compliance suite, and whoever has defined the spec is responsible
+ for writing it.,
+