# 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:** 5

<div class="post-metadata">

### Author: ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [October 16, 2019, 10:39am UTC](https://discourse.julialang.org/t/bug-shuffle-breaks-normalisation-test/29976/5 "2019-10-16T10:39:38Z")

</div>

> [@dcastel](#):
>
> Is that something that has to be done in general in Julia? Replace all == with ≈ ?

I am not sure that is a good idea, those functions serve a different purpose. And of course `≈` is not transitive.

> [@dcastel](#):
>
> Are there some guidelines/reading material about when too and when not to use it.

The underlying issue is floating point, so maybe this is helpful:

> [@PSA: floating-point arithmetic](https://discourse.julialang.org/t/psa-floating-point-arithmetic/8678):
>
> Sometimes people are surprised by the results of floating-point calculations such as julia\> 5/6 0.8333333333333334 # shouldn't the last digit be 3? julia\> 2.6 - 0.7 - 1.9 2.220446049250313e-16 # shouldn't the answer be 0? These are not bugs in Julia. They’re consequences of the IEEE-standard 64-bit binary representation of floating-point numbers that is burned into computer hardware, which Julia and many other languages use by default. Brief explanation You can t…

> [@dcastel](#):
>
> Is there also an infix notation for isapprox() ?

`≈`

---

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