Investigate precision of the vectorized TensorPrimitives implementations.

[eiriktsarpalis]

Following investigation via #99023 we identified the following vectorized implementations whose precision deviates from the tolerances specified in their scalar equivalents:

Routine	Double $\epsilon$	Single $\epsilon$
Scalar Baseline	8.8817841970012523e-16	4.76837158e-07f
Cbrt	1e-13	N/A
CosPi	Ν/Α	1e-5
Dot	1e-14	1e-5
Exp10	1e-13	1e-5
Exp2	1e-14	1e-5
Exp2M1	1e-14	1e-5
Exp10M1	1e-13	1e-5
Pow (scalar/span)	N/A	1e-5
Pow (span/span)	1e-13	1e-5
Pow (span/scalar)	1e-13	1e-5
RootN	1e-13	N/A
SinPi	1e-13	1e-4
Sum	1e-14	1e-5
SumOfMagnitudes	1e-12	1e-6
SumOfSquares	1e-12	1e-6

[ghost]

Tagging subscribers to this area: @dotnet/area-system-numerics
See info in area-owners.md if you want to be subscribed.

Issue Details

---

          What I'd like to understand is if this a variance being introduced more generally, or just for the special values we test like `MaxValue/MinValue`. If it's all or most values, then I don't think we can take the implementation. If its only for these extreme boundary values, then I think we're perfectly fine.

For a TL;DR. I think the upper boundary for a normal input is:

• float - 2^17
• double - 2^46

Beyond that we've already started with enough precision loss that its not going to be super meaningful no matter what we do.

---

For float we can exactly represent any integer up to 2^24. We can only track any fractional portion up to 2^23 (where the distance between values is 0.5). At 2^8 (256) the distance between values is 0.000030517578125, which is just enough to represent 5 significant digits of PI. For double, the same distance between values occurs at 2^37.

The ability to represent 5 digits for PI (3.1415) is a reasonably boundary at which these types of trigonometric functions can be expected to be most accurate, regardless of underlying implementation. On the more extreme end, we can represent 3 digits for PI (3.14) at 2^17 (float) or 2^46 (double). With any fewer digits we've lost enough precision that results are less meaningful, so I think this is a good maximum range for expected inputs to be accurate.

For typical inputs, we really want to expect 6-9 digits of accuracy for float and 15-17 digits of accuracy for double. With an allowance for this accuracy to taper off as the input grows in magnitude.

Originally posted by @tannergooding in #98302 (comment)

Author:	eiriktsarpalis
Assignees:	-
Labels:	area-System.Numerics
Milestone:	-

[eiriktsarpalis]

Closing as done.