Why is this expression type unstable?

General Usage
, ,
2

  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, 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 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.

1 Like