My point is that you should use neither eval(Meta.parse(...))
(which is slow) nor getfield(@__MODULE__, Symbol(...))
which is faster but still slow.
The eval(Meta.parse(@sprintf(...)))
answer was the literal answer to your question (how can you evaluate the output of @printf
as code), but you are probably asking the wrong question. This is a classic XY problem.
Since I don’t know what your ultimate goal is, I can only give a made-up example. Suppose you want to write a function integrate(f, a, b; N=100)
that computes \int_a^b f(x) dx for a user-specified function f
from a
to b
using an N
-point trapezoidal rule. You could implement this with:
function integrate(f, a, b; N=100)
dx = (b - a) / (N-1)
I = (f(a) + f(b)) * dx / 2 # endpoints
for i = 1:N-2 # interior points
I += f(i * dx) * dx
end
return I
end
This is a “higher-order function” because it takes in a function f
as an argument. For example, we could use this to approximately integrate your function DeltaAI
from 0 to 1:
julia> integrate(DeltaAI, 0, 1)
0.6931535573789361
which matches the exact answer \ln 2 \approx 0.6931471805599453 to four digits, and we can get more digits correct by increasing N
:
julia> integrate(DeltaAI, 0, 1, N=10^6)
0.6931471805600137
Notice how we can simply pass DeltaAI
as an argument. No string evaluation etcetera is required, and Julia compiles this to very efficient code. We can even define new functions on the fly to integrate, e.g.
julia> integrate(x -> x^2, 0, 1) # ∫x² ≈ 1/3
0.3333503384008435
In this way, functions are “first-class” objects in Julia — you can pass them as arguments, return them from other functions, manipulate them to make new functions, etcetera, on the fly.
You wouldn’t store numbers as strings in Julia. Don’t store functions as strings either.