# vectorize changes the result of float operations

I just discovered that vectorize can change the result of floating operations. As @Maxim rightly pointed out to me, with floating point operations you can not expect (a+b)+c = a + (b+c)
output:
so we have three different results of operations which theoretically should get the same result.
Now I wonder how to deal with this, these small drifts can have significant effects of course. (in my case with llm.mojo, it produces different texts than llm.c )

Good question! floating point numbers in Mojo already comply with IEEE 754-2008 that means they are

*not*associative (as you pointed out) and it's the same for all programming languages that comply with such protocol. So when it comes down to comparing float values they shouldn't be compared as exact values and use approximate comparison with a tolerance. You can use`assert_almost_equal`

https://docs.modular.com/mojo/stdlib/testing/testing#assert_almost_equaltesting | Modular Docs

Implements various testing utils.

If interested there's another aspect of floats like

`0.1 + 0.2 != 0.3`

. Have a look at https://0.30000000000000004.com/
Also check out this important paper https://www.itu.dk/~sestoft/bachelor/IEEE754_article.pdfThanks Ehsaan. What surprises me in the demo is that f4 which sums up the number in reverse order gets the same result as the standard vectorized version f5. My expectation would have been that f1 leads to the same result. So it seems that vectorize internally reverses the calculation

It could be a coincidence based on the numbers (step) you chose. I think to be sure you need to perform multiple tests with random numbers.

good point, you are right, with 42 the reverse order sum is same as the standard loop, and the vectorized one is different than all the others. Trying different numbers makes clear that there is no obvious rule when which version calculates the same result.