This is expected, at least according to the current spec. See https://go.dev/ref/spec#Arithmetic_operators , look for "fused multiply and add". We do use FMA on ARM64 (and some other architectures).

This is expected, at least according to the current spec. See https://go.dev/ref/spec#Arithmetic_operators , look for "fused multiply and add". We do use FMA on ARM64 (and some other architectures).

Thanks! That's indeed good to know. But if I understand the behavior correctly, and it is all about FMA. Shouldn't we at least have consistent results for each of the return statements on a specific architecture? Meaning for all compute functions:

func compute1(a, b, c Vec3) float32 {
	...
	return -x.X*a.X - x.Y*a.Y - x.Z*a.Z // v1
}

func compute2(a, b, c Vec3) float32 {
	...
	return -(x.X*a.X + x.Y*a.Y + x.Z*a.Z) // v2
}

func compute3(x, a Vec3) float32 {
	return -x.X*a.X - x.Y*a.Y - x.Z*a.Z // v3
}

func compute4(x, a Vec3) float32 {
	return -(x.X*a.X + x.Y*a.Y + x.Z*a.Z) // v4
}

they at least all produce the same results (does not necessarily require linux/amd64 == darwin/arm64)?

The + and - are the difference. They are not the same order of operation, e.g. compute1 has multiply, negate, multiply, subtract, ..., compute2 has multiply, add, multiply, ..., negate. This would also cause different operations being fused in different cases.

If it really matters, you can try adding explicit rounding, e.g. -float32(x.X*a.X) - ...

Isn't compute1 and compute3 exactly the same in its arthmetic order? They are still result in a false comparison.

I can't certainly answer regarding the influences yet without enough in-depth practice. But as far as I could imagine, it might influence the numeric stability of different solvers and convey hidden issues, which eventually cause unexpected results on different platforms (e.g., Laplacian and Poisson solvers that compute differently optimized geometric structures where one is a good geometry and the other is a faulty geometry).

The compiler is permitted but not required to use FMA for any given expression.

People who need precise control over floating-point operations can and should use conversions to float32 as @cherrymui suggested and/or call math.FMA.

Thanks for the suggestions! I will close this for now and need further develop some expertise here and see how to tacle this precisely.