On Saturday, August 30, 2014 4:52:49 AM UTC-4, Andrei Berceanu wrote:
> A few things that are still unclear: > 1. Can this approach be optimized further? I can't help the feeling that > it contains a fair amount of redundancy, especially looking at the quote > $var end kind of expressions. I can replace the macros with functions as > you suggest, but then it's not clear to me when to use a function and when > a macro. > There's no practical difference between a macro that calls a function (at macro-evaluation time, not in the generated expression) and a macro that calls a macro What I usually do is to write *everything* as functions first, to make it easier to look at the resulting expressions. Once the resulting expressions are what I want, then I convert the top-level function into a macro. In terms of optimization, the speed of the macro is irrelevant; the question is the efficiency of the generated code. Look at the output expression and see if you can identify opportunities for further optimization. > 2. I would like to see the functional form of the full matrix L (not just > element by element, but the whole matrix of expressions), in terms of the > functions \epsilon, \gamma and X. I tried with macroexpand acting on > genmatL, but that doesn't seem to work. This is basically just to convince > myself that the approach indeed works as intended. > "That doesn't work" is hard to respond to. Macros can do any code generation you want; it's just a matter of debugging. Like I said, I would write things as functions first (and pass symbolic expressions for the arguments A1,A2,A3 etcetera) and tweak it until the resulting expression is what you want, before converting the top-level function to a macro.
