So I am not terribly sure why creating a closure should should mess with
the scoping of the variables. I'm not sure this is the desired behaviour.
Maybe there is a good reason. Clearly in this scenario, the compiler is
confused by what z is.
Its just that printing a variable without implicitly
Thanks, but I think if iter 2 (line 21) makes sure that x_previous is
defined in the previous iteration. Just to be clear, the condition to check
here was g_norm g_norm_old, but I changed it to get there as early as
the second iteration.
On Tuesday, April 28, 2015 at 9:13:49 PM UTC-4, Avik
If you comment out lines 42-49, you will see that it works fine!
On Tuesday, April 28, 2015 at 9:20:49 PM UTC-4, Pooya wrote:
Thanks, but I think if iter 2 (line 21) makes sure that x_previous is
defined in the previous iteration. Just to be clear, the condition to check
here was g_norm
Yes, sorry I jumped the gun. Thanks for clarifying.
But it still does not have anything to do with Optim :)
The problem is due to defining an inline function (line 43) that creates
closure over the x_previous variable. To test this, just comment that
line (and adjust the Optim.optimize
I'm seeing the error in line 22 of your gist where you are trying to print
the current value of x_previous. However, x_previous is first defined in
line 38 of your gist, and so the error is correct and doesnt have anything
to do with Optim, as far as I can see.
On Wednesday, 29 April 2015
Ah! Thank you. I had not heard of closure before. Now, I have heard of it,
but am not sure if I can completely understand it! I guess this might be
worth being explained in the manual. One thing that is still kind of
confusing is that in your example, z is defined after the closure is
created
