By signature I only meant the list of arguments, with or without types. I guess the terminology is different in different languages (I’m used to R, where types are never specified).
What I mean is in the case where T
is not the type of x
, as in my example below, it would seem I should be adding a dummy variable y::T
to the function to pass the type, which feels inelegant.
My current solution is as follows:
function update_matrix!(m)
x = [1.2, 3.4]
m[1,1] = exp(1im*x[1]) + sin(x[2])
m[2,1] = exp(1im*x[2]) + sin(x[2])
m[1,2] = exp(1im*x[1]) + sin(x[1])
m[2,2] = exp(1im*x[2]) + sin(x[1])
end
function high_level(a, x)
m = Matrix{Complex{Real}}(undef, 2,2)
for i in 1:a
update_matrix!(m)
end
return(real(m[1,1])*x)
end
high_level(2, 1.5)
Here thankfully I can probably derive the type of m
from the type of x
, as m = Matrix{Complex{typeof(x)}}(undef, 2,2)
but if I needed to define the type of m
in a way that is unrelated to a
and x
, with a parametric type T, I understood that would require introducing a dummy variable y::T
? I guess it’s not a problem in practice, since pretty much always the type of internal objects will depend on the type of the input; unfortunately it can be hard for a newcomer to grasp what kinds of operations can be done on types – here for example I just need to do Complex{typeof(x)}
, but part of me wonders what I would do if the relation between both types wasn’t so trivial.
I probably misunderstood that it was suggested I could add an argument y
, which I could consider dummy, just for the purpose of using its type within the function,
function high_level(a, x, y::T) where {T<:Real}
m = Matrix{Complex{T}}(undef, 2,2)
for i in 1:a
update_matrix!(m)
end
return(real(m[1,1])*x)
end