A lot of functions limit tuple for which they specialize at 32 elements. It is easy to run into non-inferred code because of this, eg
z = NamedTuple{ntuple(i -> Symbol("a" * string(i)), 33)}(ntuple(i -> (1, 2.0, π, 3f0)[i % 4 + 1], 33))
g(z) = sum(values(z))
@code_warntype g(z)
I do understand the reasoning behind this limit (that said, with improvements in compile time and precompilation, I wonder if it could be relaxed now, but is just a side question).
What I am wondering about is the following: assuming that I know what I am doing, and want to use longer (heterogeneous) tuples, and have the code inferred, what is the best option?
Eg I could introduce a wrapper type and reimplement all functions that deal with it using @generated etc. But that is quite a bit of work.
4 Likes
I’m also running into this limit. What did you end up with?
Nesting named tuples. Eg instead of
(β = 1.0, σ_ε = 0.2, σ_η = 0.4)
using
(β = 1.0, noises = (σ_ε = 0.2, σ_η = 0.4))
This, incidentally, also lead to better code organization.
6 Likes
This is such a great hack, I’m taking it.
1 Like
Thanks for your kind words, but it is simply the realization of a silly mistake: specifically, if I am naming 32+ heterogeneous things in a flat container, I am doing something wrong. It does not only smell, but it reeks, and instead of trying to work around this at the compiler level I actually benefit from redesigning my code.
4 Likes
Nah man stick with bad and crazy. I want to see the compiler dispatch on your 7,300 element nested tuples
1 Like
Making it nested is just better and cleaner in general, not only for the compiler (:
So many times I see tables with columns like flux_a, err_a, flux_b, err_b, flux_c, err_c, ... – sometimes with 10-20 such columns! Great that in Julia it’s both convenient and performant to work with them more naturally, so the first thing I do is convert these to flux=(a=x+-y, b=x+-y, ...).
1 Like
ComponentArrays.jl is also a great way to switch between nested and flat representations on the fly.
2 Likes