Define built-in constants and add two circle constants

[mehmetoguzderin]

Fixes #4100

In accordance with the discussions, I have made sure to keep the normative definition concise and succinct, and move any exemplification or explanation into note since otherwise would be a denormalization of spec itself, especially for the rules of abstract float accuracy, directly linked in the text.

Per discussion at the Editors' call, I'm creating as draft. All feedback will be deeply appreciated.

TODO:

• Add a representative approximation value in the row, probably as a standalone column (double precision)
• Add code points for non-ASCII identifier names
• Add code example to illustrate why PI_2 is redundant per WGSL definitions

[github-actions]

Previews, as seen when this build job started (bdfdc64):
WebGPU _{webgpu.idl | Explainer | Correspondence Reference}
WGSL _{grammar.js | wgsl.lalr.txt}

[Kangz]

Any other constants we need? e or phi for example?

[mehmetoguzderin]

@Kangz I think that e is certainly a good addition in terms of practicality, though group decided to start with pi and tau initially. If there's consensus, I can certainly add to PR

[mehmetoguzderin]

The PR now also has an example to demonstrate numerical accuracy improvement through constants. Your review would be highly appreciated!

Since spec is not the right place, I'm attaching calculation of absolute error here (I've used 128 dps for mpmath):

import mpmath
import numpy as np

mpmath.mp.dps = 128

# Calculate delta_x with high precision
# Delta for interval from -PI/4 to 2 * TAU with 1024 steps
mpmath_delta_x = (mpmath.mpf(4 * mpmath.pi) - mpmath.mpf(-mpmath.pi / 4)) / 1024

print(f"delta_x (128-bit precision): {mpmath_delta_x}")

numpy_delta_x = (
    (np.float64(4.0) * np.float64(np.pi)) - (-np.float64(np.pi) / np.float64(4.0))
    ) / np.float64(1024)

print(f"delta_x (64-bit precision): {numpy_delta_x}")

numpy_delta_x_32 = (
    (np.float32(4.0) * np.float32(np.pi)) - (-np.float32(np.pi) / np.float32(4.0))
    ) / np.float32(1024)

print(f"delta_x (32-bit precision): {numpy_delta_x_32}")

M_PI_4 = np.float32(0.785398185253143310546875)
TAU_X_2 = np.float32(12.56637096405029296875)

numpy_delta_x_32_c = (
    (TAU_X_2) - (-M_PI_4)
    ) / np.float32(1024)

print(f"delta_x (32-bit precision constants): {numpy_delta_x_32_c}")

print(f"absolute error for 64-bit: {mpmath.nstr(abs(numpy_delta_x - mpmath_delta_x))}")
print(f"absolute error for 32-bit: {mpmath.nstr(abs(numpy_delta_x_32 - mpmath_delta_x))}")
print(f"absolute error for 32-bit constants: {mpmath.nstr(abs(numpy_delta_x_32_c - mpmath_delta_x))}")

delta_x (128-bit precision): 0.013038836697027950452603744510681530525232392526703320057757338395808808326871472894696433601273435096605595085626415823486473476
delta_x (64-bit precision): 0.01303883669702795
delta_x (32-bit precision): 0.013038837350904942
delta_x (32-bit precision constants): 0.013038837350904942
absolute error for 64-bit: 3.59085e-19
absolute error for 32-bit: 6.53877e-10
absolute error for 32-bit constants: 6.53877e-10

[ben-clayton]

Isn't the argument for not including M_PI_2 (PI/2) a good argument for omitting TAU? It's just one more character to write PI*2.

[mehmetoguzderin]

Certainly an argument in support of such thinking, although I think the consensus was to add TAU for widespread recognition, but if the group decides otherwise today, I can change it. Though even when precision is not an issue, similar constant collections seem to be including TAU these days, strengthening the case for inclusion.