# @fastmath macro accuracy

**URL:** <https://discourse.julialang.org/t/fastmath-macro-accuracy/38847>\
**Category:** General Usage\
**Tags:** numerics, fast-math\
**Created:** [May 5, 2020, 11:40pm UTC](https://discourse.julialang.org/t/fastmath-macro-accuracy/38847 "2020-05-05T23:40:24Z")\
**Posts on this page:** 1\
**Showing post:** 8

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [May 6, 2020, 4:08pm UTC](https://discourse.julialang.org/t/fastmath-macro-accuracy/38847/8 "2020-05-06T16:08:47Z")

</div>

Note that simply rearranging floating point arithmetic can be enough to yield [any value whatsoever](https://discourse.julialang.org/t/array-ordering-and-naive-summation/1929). Further, there isn’t a robust metric for what is acceptable for `@fastmath` (or C’s `-ffast-math`). The tradeoffs are rather arbitrary and dependent upon hardware capabilities.

I think the macro should be split up and killed — it’s one thing to sometimes return NaN, it’s another to reorder, and it’s yet another to arbitrarily change accuracy.

---

_[View the full topic](https://discourse.julialang.org/t/fastmath-macro-accuracy/38847)._