# Strange nan errors when mutating immutable struct arrays

**URL:** <https://discourse.julialang.org/t/strange-nan-errors-when-mutating-immutable-struct-arrays/69084>\
**Category:** New to Julia\
**Tags:** mutable-structure\
**Created:** [October 2, 2021, 2:46am UTC](https://discourse.julialang.org/t/strange-nan-errors-when-mutating-immutable-struct-arrays/69084 "2021-10-02T02:46:51Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![PatrickMcFarlane](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/patrickmcfarlane/32/50027_2.png) [@PatrickMcFarlane](https://discourse.julialang.org/u/PatrickMcFarlane)\
**Post date:** [October 2, 2021, 2:46am UTC](https://discourse.julialang.org/t/strange-nan-errors-when-mutating-immutable-struct-arrays/69084/1 "2021-10-02T02:46:51Z")

</div>

I’m working on a large economic model that involves a dynamic optimization problem. I’ve set up arrays within immutable structs to hold the solutions to the problem. The algorithm involves iterating on fixed points on these arrays. So I have “old” and “new” arrays and I compute the tolerance between them and then replace the “old” with the “new”.

I’m running into a problem where I will get small numbers of `nan` elements in the new array and some (incorrect) massive numbers as well when I mutate them. I used `@infiltrate` to diagnose the source of these. But when I do the assignment to a new test array, the `nan` elements don’t show up. In addition, if I do the assignment again to the struct within the infiltrator.jl repl, the `nan` elements will sometimes disappear.

The code leading up to the assignments is quite complicated, so I’ve just provided some screenshots below to show what’s going on. The `cPol`, `aPol`, etc., variables are views into other arrays within the `hh` struct. I checked each of the components on the right-hand side for `nan` elements and they had none.

I’d greatly appreciate any insight into this strange error.

Assignment to a new array, `test` works fine:

 ![testOk](https://global.discourse-cdn.com/julialang/original/3X/7/8/78a7192e0fdd704ce6de9ca7b996fbb7a89e9c5f.jpeg)

Assignment to the struct array shows `nan` errors:

 ![MutateImmutableArray1](https://global.discourse-cdn.com/julialang/original/3X/4/4/442499073dbb7433e08448b0d92bd66869e155f5.jpeg)

Assigning again to the struct array and `nan` errors disappear:

 ![MutateImmutableArray2](https://global.discourse-cdn.com/julialang/original/3X/4/6/46943087e6d2a6685860d36c7a0e4b5fae6d78c6.jpeg)

---

<div class="post-metadata">

**Author:** ![mauro3](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mauro3/32/292_2.png) [@mauro3](https://discourse.julialang.org/u/mauro3)\
**Post date:** [October 2, 2021, 9:23am UTC](https://discourse.julialang.org/t/strange-nan-errors-when-mutating-immutable-struct-arrays/69084/2 "2021-10-02T09:23:46Z")

</div>

I don’t think it’s possible to help here without a test case (certainly not for me). And if the test case is large, as you said, it might still be tricky to help. But if it is indeed as you describe, then this is a bug in Julia. So it would be good if you can reduce the test case as much as possible and post again here with code to run.

---

<div class="post-metadata">

**Author:** ![Sukera](https://avatars.discourse-cdn.com/v4/letter/s/ce7236/32.png) [@Sukera](https://discourse.julialang.org/u/Sukera)\
**Post date:** [October 2, 2021, 9:55am UTC](https://discourse.julialang.org/t/strange-nan-errors-when-mutating-immutable-struct-arrays/69084/3 "2021-10-02T09:55:55Z")

</div>

Can you post the lines of code you’re showing as text instead of a screenshot? Would make it easier to debug. Also, having a small example that shows the problem would be helpful for debugging (i.e. a small reproducible example, see [here](https://discourse.julialang.org/t/please-read-make-it-easier-to-help-you/14757)).

Are you perhaps running with `--fast-math` (which can change floating point results depending on the exact code that’s run - such as using a broadcasted assignment loop vs. not using one)?

---

<div class="post-metadata">

**Author:** ![PatrickMcFarlane](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/patrickmcfarlane/32/50027_2.png) [@PatrickMcFarlane](https://discourse.julialang.org/u/PatrickMcFarlane)\
**Post date:** [October 2, 2021, 5:32pm UTC](https://discourse.julialang.org/t/strange-nan-errors-when-mutating-immutable-struct-arrays/69084/4 "2021-10-02T17:32:16Z")

</div>

Thanks for the quick responses. I’m not using `--fast-math`…I haven’t included it anywhere in my code and I don’t think any of the packages I’m using would be using it either.

I’ll do some testing tonight and see if I can provide a minimally reproducible example.

---

<div class="post-metadata">

**Author:** ![PatrickMcFarlane](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/patrickmcfarlane/32/50027_2.png) [@PatrickMcFarlane](https://discourse.julialang.org/u/PatrickMcFarlane)\
**Post date:** [October 2, 2021, 11:46pm UTC](https://discourse.julialang.org/t/strange-nan-errors-when-mutating-immutable-struct-arrays/69084/5 "2021-10-02T23:46:39Z")

</div>

Looks like I’ve solved the problem.

The line of code that was leading to the error was:

```julia
@views hh.WPnew[:,:,iz,iβ,iTE,iw̄] .= hh.cPol_e[:,:,iz,iβ,iTE,iw̄].^(1-σ)./(1-σ) .- ρ[iz] .* γ_s.* hh.sPol_e[:,:,iz,iβ,iTE,iw̄] .^(1 + φ_s) ./ (1 + φ_s) +
 βvals[iβ] .* expectation_e(βtrans[iβ,:], ztrans[iz,:], itpW, itpU, hh.dPol_e[:,:,iz,iβ,iTE,iw̄], hh.aPol_e[:,:,iz,iβ,iTE,iw̄], w̄P, EIbenP, zvals, βvals, 1 .- ρ[iz] .+ ρ[iz]*hh.sPol_e[:,:,iz,iβ,iTE,iw̄].*fh[iz], ρ[iz]*(1 .- hh.sPol_e[:,:,iz,iβ,iTE,iw̄].*fh[iz]))

```

In the `expectation_e` function, I had used the `similar()` command. After poking around a bit on here, I learned that `similar()` can sometimes produce nan elements. These then just got carried through the rest of the operations in that line of code.

It was just luck that when I called the function again, `similar()` didn’t spit out any nan elements.

Sorry for taking up everyone’s time with this.