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 implicitl
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 u
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 call
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_
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,
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 01
