acceptable floating point number error ranges

OpenGL
1

It would be good idea if the amount of the acceptable errors are specified for each of the functions that set floating point state variables. Inside the gl functions there maybe many operations(div/mult), casting(float->int) and floor (0.52->0.5) that can generate difference between the hand computed and computer computed results. These differences can be ignored if there is specified precision.

i.e:
setting a color value to 0.5 for RED

actually makes this value to

0.5019608139991760 when it is get.

In this case this difference is not a problem since red color has 256 levels and the acceptable error can be calculated with this information(1/256).

But sometimes we cannot determine the acceptable amount of error. glLight has a complex formula to inspect. This function can be hw accelerated and its amount of error(difference) can change with hw. So for each of the gl calculations we need a limit for the error.

If we do not have limits for errors we may see different colors with the same code for different gl libraries. Thus, this won’t be standart anymore. Also we cannot determine if this implementation is opengl compliant or not.

We can add a field in the function descriptions section of the reference manual that specifies the amount of the acceptable difference between the real and computer values.

2

This already exists. Every compliant OpenGL implementation must follow a standard for its floating point and integer calculations. The standard explicitly states the acceptable range of values for any calulation performed. Specifically, it gives the minimum number of bits that the calculations must be performed within.

3

If we do not have limits for errors we may see different colors with the same code for different gl libraries.
The OpenGL specification does not require pixel-color accuracy to be compliant. They tend to be intensionally vague, in order to allow hardware developers to create implementations without inhibiting their ability to optimize too much.

4

If we do not have limits for errors we may see different colors with the same code for different gl libraries. Thus, this won’t be standart anymore. Also we cannot determine if this implementation is opengl compliant or not.

This is already happening and floating point precision isn’t the only issue.

For example, different companies use different filter kernels for doing multisampling so 4x FSAA on card A is not same as 4x FSAA on card B

The same applies to rasterization. The algorithm used for rasterizing primitives is not given in GL’s spec. You can use what you want and end up coloring different pixels than your competitor.

The same applied to GL’s processing pipeline and many other cases.