-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Variable initialisation #170
Comments
Does it matter, it will be overwritten anyway? To initialise arrays as with NaNs we would need to do julia> fill(convert(NF,NaN),2,3)
2×3 Matrix{Float16}:
NaN NaN NaN
NaN NaN NaN for example, such that for ever |
Sometime is hard to distinguish unset or improperly used variables down at the bottom of the stack and for debugging and assertions having NaNs helps... If there is no difference in terms of performance etc, I think it would be safer to use NaNs where possible. |
No it's not a performance issue. In both cases memory is allocated and filled with bits. Doesn't matter what those are. julia> using BenchmarkTools
julia> c = NaN
julia> @btime fill($c,1000,1000);
1.160 ms (2 allocations: 7.63 MiB)
julia> c = 0.0
julia> @btime fill($c,1000,1000);
1.163 ms (2 allocations: 7.63 MiB) Note that in the dynamics we allocate with zeros, and I never had a debugging-related issue with this. Happy for you to convert the initialisation for ColumnVariables to init with NaN, if people prefer that. I would suggest to define function nans(::Type{T},dims...) where T
return fill(convert(T,NaN),dims...)
end in utility_functions.jl such that julia> nans(Float16,2)
2-element Vector{Float16}:
NaN
NaN
julia> nans(Float32,2)
2-element Vector{Float32}:
NaN
NaN |
|
@milankl great, thanks. Will add this to my current PRs. Feel free to close. |
Variables (e.g.
column_variables.jl
) are initialised with zero. Is there any reason for doing so? If not why not usingNaN
for floats andtypemax
ortypemin
for ints?The text was updated successfully, but these errors were encountered: