Re: [Gretl-devel] slight qform() generalization

On Wed, 1 Oct 2014, Riccardo (Jack) Lucchetti wrote: > On Wed, 1 Oct 2014, Allin Cottrell wrote: > >>> I had a look at the source and it occurred to me that we may try to >>> intercept expressions like x'x and apply a specialised algorithm (which >>> should be somewhat faster) for those: Allin, correct me if I'm wrong, but >>> we could check for "l" and "r" for being the same guy in the B_TRMUL >>> branch of the big "switch" inside eval (line 10501 of geneval.c) and >>> then, if so, simply call matrix_multiply_self_transpose(). No? >> >> gretl_matrix_multiply_mod() already checks for a identical to b and >> calls matrix_multiply_self_transpose() if it's appropriate. > > Yes, I saw that, but the check is based on the equality between the two > pointers a and b; my suggestion was based on the impression that l->v.m and > r->v.m may be distinct as a result of the parsing process even though the > original parsed string contained an expression like > "<something>'<something>". No, if you say "X'X", then the "l" and "r" terms will be the same matrix pointer. They wouldn't be the same if you said something like "(A*B)'(A*B)" since each of the operands would be created on the fly, separately. But that's a different issue; identifying them as "the same matrix", numerically, would in general be a waste of time.

>> In general, doing tricksy things to try to speed up matrix operations in >> gretl is likely to slow them down. We've spent a lot of time trying to get >> things working optimally when coded "naturally". > > That's true. And besides, applyimng a specialised algorithm would probably > make a noticeable difference only with HUGE matrices. For example, applying > the specialised algorithm to x'x when x is a column vector may even slow > things down. Not sure about that. The specialized algorithm matrix_multiply_self_transpose() seems to be worthwhile quite generally. Unfortunately that's not something you can test just via a hansl script (since any alternative hansl formulation that forces X-transpose times X _not_ to use the special algorithm will necessarily be more complicated and so not a fair comparison). But you can do the test by commenting out the relevant clause in gretl_matrix_multiply_mod. I find that when X is 50x5 (substantial but not huge) the special code knocks maybe 25 or 30% off the time;

with X a column vector it doesn't help, but doesn't seem to hurt either.