Søren Hauberg wrote: > >>>> - c = 1 + sum ((x-y)(:)'*z*((x-y)(:))); >>>> + c = 1 + sum (vec(x-y)'*z*(vec(x-y))); >>> What is the purpose of this (and similar) change? >> >> Its again an issue with oct2mat, which can not deal well with (x-y)(:), >> especially if these are used within more complicated constructs. Using >> vec() avoids this problem. > > Can't 'oct2mat' just call 'vec' for these types of expressions? It just > seems to me that changing code to fit 'oct2mat' is not the right > approach (it should be the other way around; that way 'oct2mat' would be > more useful). In this case it might even have an impact on performance, > though I doubt it matters.
No, its not possible to have a general purpose solution for the (...)(:) issue. Lets look at the following example [F (x-y)(:)]. If F is a function, it should be converted to [vec(F(x-y))], but if F is a variable, the correct translation is [F vec(x-y)]. oct2mat can not know which is correct, because it needs to know the context of this expression. In worst case, whether F is a function or variable is determined only at runtime. I'm not sure there is a "right" or "wrong" approach in coding style. If there is some official documentation, what is the "right" coding style, I'd like to learn about it. What I see is that some code is incompatible, and I try to keep the code in my repository compatible. Of course, I could maintain two repositories, but I'm too lazy to do this. Alois ------------------------------------------------------------------------------ _______________________________________________ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
