Using eval() within a macro is almost always not what you should be doing. Macros should return code that may depend on the values of the input symbolically. In general, I would try writing down the expression that you want to generate, and then try to reproduce it in the macro, using macroexpand() for debugging.
On Saturday, August 16, 2014 1:39:59 PM UTC-6, Tomas Krehlik wrote: > > The packages are certainly cool, but do not achieve what I want. I > probably explained myself wrongly, so I have a minimal example, which I > would like to turn to macro and cannot make it work. :-/ > > Here is how it works without macro: > > function β(from, to, lag) > # vars, lags and ntyp should be taken from the already estimated > object > col = fill(0.0, vars*lags + vars*ntyp) > col[(from + to)*lag] = 1.0 > return col > end > > function betaa(from, to, lag) > return β(from, to, lag) > end > > test = :(begin > betaa(1,2,3) + 2.0 * betaa(2,3,1)=1 > 3.0 * betaa(2,1,3) + betaa(2,3,4) = 1000 > end) > > # Hardcode so far > vars = 20 > lags = 15 > ntyp = 20 > ind = [typeof(test.args[i])==Expr for i=2:length(test.args)] > ind = ([1:length(ind)][ind])+1 > R = apply(hcat,[eval(test.args[i].args[1]) for i=ind]) > r = [eval(test.args[i].args[2]) for i=ind] > > Gives the proper matrices, but when I do > macro restrictions(ex) > vars = 20 > lags = 15 > ntyp = 20 > ind = [typeof(ex.args[i])==Expr for i=2:length(ex.args)] > ind = ([1:length(ind)][ind])+1 > R = apply(hcat,[eval(ex.args[i].args[1]) for i=ind]) > r = [eval(ex.args[i].args[2]) for i=ind] > (R, r) > end > > @restrictions begin > betaa(1,2,3) + 2.0 * betaa(2,3,1)=1 > 3.0 * betaa(2,1,3) + betaa(2,3,4) = 1000 > end > > It does not work and I have no idea why, probably still too advanced > concept for me. Also the size of the column that is returned from betaa > depends on size of the system, that will be stored in another variable so > it would be cool if the betaa function could be evaluated in the macro > environment so that it would use the vars, lags and ntyp from the within > macro. > > Thanks for any help with this. > > > On Saturday, 16 August 2014 17:44:26 UTC+2, Miles Lubin wrote: >> >> JuMP is also a good place to look. >> >> On Saturday, August 16, 2014 8:11:04 AM UTC-6, Stefan Karpinski wrote: >>> >>> Have you looked at CVX? I feel like it may be relevant. >>> >>> On Aug 16, 2014, at 8:47 AM, Tomas Krehlik <[email protected]> wrote: >>> >>> I have a package that implements much of vector autoregression >>> estimation and I would like to develop a macro that would implement domain >>> specific language for imposing linear restriction in multidimensional >>> time-series models. Of course, the user could input the restrictions using >>> some matrices, however I tend to think that they will be much less readable >>> than if I implement this macro and I hope it should not be that bad. >>> Typical example would be: >>> >>> restr = @restrictions begin >>> 2 beta[1,2,1] - beta[2,1,3] = 10 >>> beta[1,3,1] - beta[1,4,1] = 0 >>> end >>> >>> and the restr would be a tuple with matrix and vector after this. >>> >>> The beta has the following structure beta[from, to, lag]. The macro >>> should take each line and parse it and form proper restriction matrix R >>> that will be made from the signs and indexes at betas and vector r. So I >>> need to parse the signs, constants, and indeces of betas and the thing that >>> is after the equality. >>> >>> Am I right that the right direction is parsing the lines with regular >>> expressions to create the right matrices, or do you have suggestion for >>> better approach? Any further reference for something similar (or useful >>> resource) that has been done before is also very appreciated. >>> >>> Related on that note, is there any function to return all matches from >>> regex? That seems to be the biggest bottleneck so far. >>> >>> Any comments appreciated. Thanks! >>> >>>
