# Bug? shuffle() breaks normalisation test

**URL:** <https://discourse.julialang.org/t/bug-shuffle-breaks-normalisation-test/29976>\
**Category:** Internals & Design\
**Tags:** bug\
**Created:** [October 16, 2019, 9:12am UTC](https://discourse.julialang.org/t/bug-shuffle-breaks-normalisation-test/29976 "2019-10-16T09:12:10Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [October 16, 2019, 1:29pm UTC](https://discourse.julialang.org/t/bug-shuffle-breaks-normalisation-test/29976/6 "2019-10-16T13:29:36Z")

</div>

It’s important to understand what `≈` does: by default it checks to see if two floating point values are equal for the first half of their significant digits. That’s pretty lenient but also quite standard. To be used with caution but also essential when checking results that can depend on numerical round off. I’m afraid the only answer here is to have some grasp of numerical analysis and to use judgement. Replacing all equality checks with `≈` is definitely not a good idea. Nor would it even be sufficient: `0.0` is never approximately equal to any non-zero value since it has no scale so you can’t know which bits should be considered significant or not. As the docs for `≈` say:

> [@](#):
>
> Note that `x ≈ 0` (i.e., comparing to zero with the default tolerances) is equivalent to `x == 0` since the default `atol` is `0`. In such cases, you should either supply an appropriate `atol` (or use `norm(x) ≤ atol`) or rearrange your code (e.g. use `x ≈ y` rather than `x - y ≈ 0`). It is not possible to pick a nonzero `atol` automatically because it depends on the overall scaling (the “units”) of your problem: for example, in `x - y ≈ 0`, `atol=1e-9` is an absurdly small tolerance if `x` is the [radius of the Earth](https://en.wikipedia.org/wiki/Earth_radius) in meters, but an absurdly large tolerance if `x` is the [radius of a Hydrogen atom](https://en.wikipedia.org/wiki/Bohr_radius) in meters.

In particular, summation, even though it seems like an innocuous operation is sensitive to data ordering. In fact, you can sum the same set of numbers in different orders and get basically any possible result:

> [@Array ordering and naive summation](https://discourse.julialang.org/t/array-ordering-and-naive-summation/1929):
>
> One of the first things you learn in numerical analysis is that floating-point operations are not associative. A classic example is this: julia\> (0.1 + 0.2) + 0.3 0.6000000000000001 julia\> 0.1 + (0.2 + 0.3) 0.6 I was thinking of ways to make floating-point summation independent of the order of the summands without making the performance much worse (this is a hobby of mine). Julia currently uses a pairwise summation algorithm, which is much better than naive left-to-right reduction while havin…

We don’t use naive summation by default in Julia, so things aren’t quite that bad, and if you’re only adding up positive values it’s not possible to have such a pathological situation, but keep this in mind.

---

_[View the full topic](https://discourse.julialang.org/t/bug-shuffle-breaks-normalisation-test/29976)._