Stephen Canon

@dabrahams There are a bunch of reasons not to use the DoubleWidth pattern. Most are minor, but two of them are significant: - Sizes that are not powers of two...

There's an inherent tradeoff; the "use LLVM large integers" approach benefits from all the existing integer optimizations in LLVM, but perversely locks away some optimizations that become available when the...

Yup. This is a problem that no one has a good solution to yet. I have a few ideas, but haven't had time to sort through them. As you suggest,...

> Second, the problem curve approaches cos(y) = 0 as x increases, so cosMinusOne(y) is actively harmful in that region for large x. Well, no, because the alternative factorization (`exp(x)...

Right, `exp(x) * cos(y) - 1` is about as good on that region, but not appreciably better. The expMinusOne alternative is always strictly worse. So there's no reason to use...

Forgot to address z very nearly 0 😀 In this case, expMinusOne(x) cos(y) + cosMinusOne(y) becomes x*1 + y^2/2 = x, so there's no loss of accuracy in just using...

It's no less accurate than the alternatives we have (as explained), not significantly slower, and yields considerable simplicity in the implementation. What's not to like?

Hi @pashabou -- quaternions are definitely in-scope, this is a reasonable suggestion. A couple quick notes: - a quaternion implementation should wrap the SIMD4 type from the Standard Library -...

@markuswntr Thanks! As a heads-up, I'm a little bit swamped for the next few days, but I'll give your PR a quick skim, then provide more detailed feedback sometime next...

Yes, the system math library functions do not generally produce identical results on different platforms. It's a possible long-term goal for Swift Numerics to provide portable implementations, but it's *very*...