# Understanding @report\_code output

**URL:** <https://discourse.julialang.org/t/understanding-report-code-output/116000>\
**Category:** General Usage\
**Tags:** broadcasting, type-stability, staticarrays, jet\
**Created:** [June 22, 2024, 12:03am UTC](https://discourse.julialang.org/t/understanding-report-code-output/116000 "2024-06-22T00:03:17Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![miguelborrero](https://avatars.discourse-cdn.com/v4/letter/m/eb9ed0/32.png) [@miguelborrero](https://discourse.julialang.org/u/miguelborrero)\
**Post date:** [June 22, 2024, 12:03am UTC](https://discourse.julialang.org/t/understanding-report-code-output/116000/1 "2024-06-22T00:03:17Z")

</div>

Hi there,

This is my first time using JET.jl to fix the type-instability issues of my code. I am aware that maybe asking without a reproducible example might be a stretch but I will try anyways.

My function takes as an argument an SVector{9, Float64} labeled as `uJ_grid` then in the loop seen in the screenshot below it gets added a number and therefore the new `biased_uJ` is also an SVector{9, Float64}. This static array gets broadcasted by one of the functions returned by:

```julia
initial_bank_cdf::Vector{Function} = [x -> 1.0 - hermite5_cdf(params[a], initial_bank_μ, initial_bank_σ)(-overall_scale * (x + scaled_κ)) for a in param_indices.bank_params]

```

This screenshot summarizes the above:

 ![Captura de pantalla 2024-06-21 a la(s) 16.58.24](https://global.discourse-cdn.com/julialang/original/3X/6/5/653ea51e3faa5d46e2d5cc4b8f132bd849b2fd13.png)

And I get the following possible error regarding type instability:

 ![Captura de pantalla 2024-06-21 a la(s) 17.02.49](https://global.discourse-cdn.com/julialang/original/3X/9/2/923425dbae1e7272f8b666e942d46cc359734139.png)

Any help to understand the message and how to fix it would be greatly appreciated. Thanks in advance!

---

<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:** [June 22, 2024, 1:19am UTC](https://discourse.julialang.org/t/understanding-report-code-output/116000/2 "2024-06-22T01:19:36Z")

</div>

Not sure if it’s the entire reason because this isn’t a MWE, but indexing a `Vector{Function}` and involving the inferred-`Function` element in a call requires a runtime dispatch because `Function` is abstract. If you don’t need to add or change elements to `initial_band_cdf`, you might improve the situation if you remove the `::Vector{Function}` annotation and let the array literal try to make a concrete element type. That said, full inferrability would also depend on the captured variables not being reassigned.

Don’t post screenshots of code, paste text between 2 lines of triple-backticks (```), it’s more readable. If you think it’s too long, then put it in a Hide Details block (click the settings gear icon in the comment’s interface to see the option).

---

<div class="post-metadata">

**Author:** ![miguelborrero](https://avatars.discourse-cdn.com/v4/letter/m/eb9ed0/32.png) [@miguelborrero](https://discourse.julialang.org/u/miguelborrero)\
**Post date:** [June 23, 2024, 4:06pm UTC](https://discourse.julialang.org/t/understanding-report-code-output/116000/3 "2024-06-23T16:06:21Z")

</div>

Thanks a lot for your answer. It worked! Given my low experience with Julia and computing in general let me ask two quick follow up questions to try and understand fully what you mean:

1. Without the annotation, the compiler can try and infer the type of the return based on the array literal but the annotation prevents it? My current understanding is that the annotation invokes a type check at run time giving an error if the type ends up not being `Function` but why is this making a difference with respect to letting the compiler go beyond this?

2. “That said, full inferrability would also depend on the captured variables not being reassigned” I did not understand this, could you please add a bit of verbosity?

Thanks a lot in advance, and sorry for the questions. Just trying to improve my Julia understanding.

---

<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:** [June 23, 2024, 6:56pm UTC](https://discourse.julialang.org/t/understanding-report-code-output/116000/4 "2024-06-23T18:56:25Z")

</div>

> [@miguelborrero](#):
>
> the compiler can try and infer the type of the return based on the array literal but the annotation prevents it?

I should first mention that the typical way to annotate an element type is in array literal syntax like `initial_bank_cdf = Function[...]`. That would be directly involved in the instantiation. What `initial_bank_cdf::Vector{Function}` does is force all assignments to that variable to do the conversion and assert the conversion worked; if the instance was already the type it would skip the instantiation. In your case, you made a vector with a more specific type but then instantiated a `Vector{Function}` copy, which is probably wasteful.

Given no annotation, the element type is figured out in an inner function call, and it could be handled at compile-time given the right circumstances. Given an annotation or elements of all the same type, it’s handled by dispatch, which could also be handled at compile-time. An annotation is lowered to providing the type as an argument to a function call; the compiler can’t optimize away from your choice. That has its uses, now you can `setindex!` or `push!` with arbitrary `Function` subtypes, with the obvious cost of performance due to runtime dispatch.

> [@miguelborrero](#):
>
> depend on the captured variables not being reassigned” I did not understand this

[Performance of captured variable - The Julia Language](https://docs.julialang.org/en/v1/manual/performance-tips/#man-performance-captured)  
While there are possible improvements to the situation, don’t expect it to go as far as some commenters might claim. There are fundamental limitations to call-wise type inference, capturing variables that are reassignable everywhere, and methods sharing instances.