Monogame / Xna basic 3D Vector rotation math - vector

Question

I am struggling with some basic vector rotations in Monogame.
I have a 3D forward facing unit vector (0, 0, -1) and simply want to rotate them 180 degrees around the Y axis (up). Here is the code:
[Fact]
public void Vector_Rotation()
{
Vector3 forward = Vector3.Forward;
float angle = (float)Math.PI;
Vector3 dirQuat = Vector3.Transform(forward, Quaternion.CreateFromAxisAngle(Vector3.Up, angle));
Vector3 dirMatrix = Vector3.Transform(forward, Matrix.CreateRotationY(angle));
}
Expected result
dirQuat = (0, 0, 1);
dirMatrix = (0, 0, 1);
Actual result
dirQuat = (8.742278E-08, 0, 1)
dirMatrix = (8.742278E-08, 0, 1)
I would expect a unit vector of the opposite of forward (0, 0, 1). I am new to the Monogame framework, have I missed something fundamental here?
Thanks in advance for any advice

Answer 1

As correctly pointed out by britter, the discrepancy is caused by the accumulation of error of the float operations. This is well described elsewhere on this site, but I will give the short answer here.
Main takeaway points:
Computers work in a finite amount of bits. In base 10, 1/3 (.33333333333333333...) cannot be exactly represented in a finite number of bits.
Multiplying two 32-bit Int numbers produces a 64-bit result. Which is then chopped to only include the 32 most significant bits when stored. This integer example when applied to Floats is always worse (since not every bit in FP32 is data) and varies with exponent differences in value (i.e. Errors are minimized when both numbers are between 0 and 1).
The minimal absolute recognizable difference between two Floats is given by Float.Epsilon. In other words, subtracting any two non-identical Float values, can result in a value up to Float.Epsilon=1.401298E-45
So why is your expected result of 0 returning 8.742278E-08 The error comes from the summation of errors during the intermediate matrix multiplications and accumulation steps, the first be the truncation of PI: float angle = (float)Math.PI; The impact of #2 permeates every aspect of the final design.
The only mildly surprising thing about your result is the Quaternion transform does not introduce more error into the final product due to the additional matrix dimension, until I realized the two function calls produce the same exact transform matrix(the additional dimension matrix was all zeroes), much of the discrepancy comes about in these two calls.
The rest of the error is manifested in the last matrix multiply Vector3.Transform(forward,
It not surprising result given the number of multiplies occurring per step.