I have these two unit vectors pulled from runtime
local a = Vector3.new(-0.5460056662559509, -0, -0.8377814888954163)
local b = Vector3.new(0.5460057854652405, -0, 0.8377814888954163)
I’m not entirely sure what’s going here, so I wouldn’t be surprised if this was intended behavior.
However the problem I was facing was that I was using the dot product of two unit vectors for math.asin, which throws a fit if you give it a value less than or greater than 1. It was a real head scratcher to deal with.
#kinda version in python
import numpy as np
vec1 = np.array([-0.5460056662559509, -0, -0.8377814888954163])
vec2 = np.array([0.5460057854652405, -0, 0.8377814888954163])
print(np.dot(vec1, vec2)) # < -1 !!!
Looks to be just standard floating point shenanigans. It should probably be noted somewhere that you shouldn’t rely on standard rules about dot products, but probably not something they can fix.
Calculators work the same and get the same result in the backend, but they automatically round the number displayed on the frontend to prevent confusion.
However, a game engine and a calculator are not the same thing, a game engine is slightly more complex, I suppose?
So, if you want a rounded result, you’ll have to do it yourself, just as these calculators do.
calculators use a slower and more precise arithmetic
floating point arithmetic is often used because of its speed and high precision
in a game where physics and lighting and a lot of other stuff are calculated 60 or more times per second then the calculations have to be optimized and the small inaccurateness of floating point arithmetic is negligible and doesn’t affect anything
this isn’t a studio bug this is an intended behavior
Calculators and game engines are far apart. Calculators work on precision while game engines work on performance. If a game engine was to work on precision then you would get 10 FPS.