Update behavior-math-clamp-nan.md

This commit is contained in:
Arseny Kapoulkine 2023-07-30 20:18:47 -07:00 committed by GitHub
parent 5cdd85f3b9
commit ce84989457
Signed by: DevComp
GPG key ID: 4AEE18F83AFDEB23

View file

@ -31,7 +31,7 @@ This can be a problem if:
As a consequence of this change, `math.clamp` return value `r` will always satisfy `a <= r <= b`.
Note that if the input or one of the limits is a negative zero we will not guarantee that the sign of the output is preserved; positive and negative zeros are considered equal under this proposal.
The behavior of NaN clamping outside of Luau varies. Shading languages (HLSL, GLSL in Vulkan, MSL in Metal) typically guarantee that `clamp(t, a, b)` is equal to a when t is NaN; C++ `std::clamp` provides no guarantees and in fact treats NaN as a technically-invalid input; Rust preserves NaN; Zig returns the upper limit. Swift does not implement clamp for floats. Despite the differences, we believe that for Luau domain guaranteeing that the result is in the specified range is more valuable than preserving NaN, and returning the lower limit is more consistent with industry practice than returning upper limit.
The behavior of NaN clamping outside of Luau varies. Shading languages (HLSL, GLSL in Vulkan, MSL in Metal) typically guarantee that `clamp(t, a, b)` is equal to a when t is NaN; C++ `std::clamp` provides no guarantees and in fact treats NaN as a technically-invalid input; C#, Rust and Julia preserve NaN; Zig returns the upper limit. Despite the differences, we believe that for Luau domain guaranteeing that the result is in the specified range is more valuable than preserving NaN, and returning the lower limit is more consistent with industry practice than returning upper limit.
> The following text is non-normative as it relates to the specific implementation consequences.