David Neto

> MM: Think that’s consistent. When the future “make math work” according to IEEE extension teh compiler would not max or round. Fits naturally. KG: People then have porting issues...

If people write code which tries to do the equivalent of sqrt(-1) or acos(2) then their algorithm is bad and they should fix their algorithm. The spec should give implementations...

In #3272 @litherum argues > Portability is way less urgent because the out of bounds will almost never happen. The same argument would apply here: math algorithms with domain errors...

Summarizing for myself (not the official minutes): - for compile-time evaluation, domain errors (as captured [above](https://github.com/gpuweb/gpuweb/issues/3253#issuecomment-1215906330)) are shader-creation errors. Already the spec says, where "one of these types" is AbstractInt...

Also, we said: - divide by zero, in integers is invalid in a const-expr

Compile-time side has all landed, I believe, and is not blocked by runtime side. Close this one?

That's the difference-of-squares factorization. And that's allowed by Vulkan by the wording at [Precision and operation of SPIR-V instructions](https://registry.khronos.org/vulkan/specs/1.3-extensions/html/vkspec.html#spirvenv-precision-operation) > Inherited From …​ Where an operation’s precision is described as...

acosh is interesting. Yes, acosh(1) = 0, but also has a *vertical* asymptote at approaching x=1 from above. So it's a worst case scenario w.r.t. ULPs errors: The infinitely precise...

Also, expect a similar problem for asymptotes of atanh(x) "inerhited from log( (1 + x ) / (1-x) ) * 0.5" Asymptotes as x -> -1 from above and x...

> sqrt(x) inherits from 1/inversesqrt(x) Ah, got it.