# Why is this expression type unstable?

**URL:** <https://discourse.julialang.org/t/why-is-this-expression-type-unstable/80648>\
**Category:** General Usage\
**Tags:** question, type-stability, symbolics\
**Created:** [May 7, 2022, 4:02am UTC](https://discourse.julialang.org/t/why-is-this-expression-type-unstable/80648 "2022-05-07T04:02:52Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [May 9, 2022, 3:02am UTC](https://discourse.julialang.org/t/why-is-this-expression-type-unstable/80648/2 "2022-05-09T03:02:37Z")

</div>

1. On v1.7.2, this phenomenon also happens when `Symbolics` is omitted and the global `z` is changed to `z=0`, so the problem doesn’t seem to be in `Symbolics`. The rest of my comment is about this `z=0` version.

2. Changing `L2` to `sum([...])` doesn’t change anything, so this might be a matter of summing over a generator versus over an array (which `map` makes).

3. The same phenomenon also happens if you run either `Pⱼ(z,x,1,n)`, `L1(z, x, y, n)`, or `L2(z, x, y, n)` instead of `@code_warntype L2(z, x, y, n)` between the 2 runs of `@code_warntype L1(z,x,y,n)`. Running `δⱼ(z,x,1,3)` was not enough.

4. If you run `Pⱼ(z,x,1,n)`, `L1(z, x, y, n)`, `L2(z, x, y, n)`, or `@code_warntype L2(z, x, y, n)` in a fresh session first, `@code_warntype L1(z,x,y,n)` is type-stable on its first try afterward.

5. These Github issues ([18695](https://github.com/JuliaLang/julia/issues/18695), [43330](https://github.com/JuliaLang/julia/issues/43330)) seem related, but I couldn’t find anything about `code_warntype` “changing its mind” like this in those issues or other linked issues. I would really highlight that detail, you could even edit your post’s title to mention it. You could also open a new Github issue, see where it goes.

Due to work done in [another thread](https://discourse.julialang.org/t/need-help-with-incomprehensible-typeinference/81056/6) about inconsistent inference, I also identified:

1. If `@code_warntype L1(z,x,y,n)` reports type-stability, then you redefine either `δⱼ` or `Pⱼ`, it will cause the next `@code_warntype L1(z,x,y,n)` to report type-instability. This re-unstabilizing effect does NOT occur if you redefine `L1` or `L2`.

2. `Test.@inferred L1(z, x, y, n)` can throw a `ERROR: return type Float64 does not match inferred return type Any` even when `@code_warntype` is inferring a `Float64` return type. `@inferred` is successful only if `Pⱼ` is compiled before `L1` is; switch the order (such as by only running `L1`) and `@inferred` gets stuck at that error; if it gets stuck at that error, redefine `L1` to “undo” `L1`’s compilation and it infers successfully again.

3. All of the above is reproducible on v1.4.1, so this isn’t a new regression.

My initial guess was that `Pⱼ` having been compiled seems to be a critical factor, but I could not claim that `@code_warntype L2(z,x,y,n)` compiles `Pⱼ`, let alone claim that’s how it triggers `@code_warntype L1(z,x,y,n)` to report type-stability.

---

_[View the full topic](https://discourse.julialang.org/t/why-is-this-expression-type-unstable/80648)._