Re: compound operators - what next?

[dbateman]

Jaroslav Hajek-2 wrote:
> 
> My top candidate is optimizing expressions like diag(v)*A because row
> and column scaling tend to be quite common in my work (what about
> yours?)
> Since this will be more like a syntactic sugar (the above
> optimizations really use different algorithms, or at least differently
> optimized), I do not consider it that important; however, diag(v)*A is
> IMHO more readable than dmult (v, A) (btw. what you do in Matlab?)
> I see 3 ways open here:
> 
> 1. implement compound operators diag_mul, mul_diag, diag_ldiv,
> div_diag, so that the following expressions would get optimized:
> diag(v)*A, A*diag(v), diag(v)\A, A/diag(v). Perhaps some checking will
> be needed if `diag' refers to the intrinsic function.
> 

But then if the user wrote d=diag(v); d*A instead your optimization would be
lost.



> 2. this is suggested in Octave's old TODO: make v.*A work like
> diag(v)*A. I don't like it much; but it's an option.
> 

Sometime around 2.1.43 Paul Kienzle implemented this. The patch for it
stayed in octave-forge for years and as NDArrays were added afterwards
became unusable. I suspect John doesn't really like the idea either.



> 3. make `diag' and `eye' actually output special objects (i.e.
> specialize octave_value for holding DiagMatrix). This would be the
> most complex, since it would allow doing things like:
> D = diag (v); % create scaling matrix
> S1 = D*S;  % scale
> S2 = S1 / (D+lambda*eye (n))
> It would also partially eliminate the need for spdiag and speye,
> because things like S+eye(n) or sparse(eye(n)) would work efficiently.
> The question here is sensible diagonal matrix arithmetic vs. matlab
> compatibility. For instance, should exp(D) for D diagonal only
> exponentiate the diagonal? (this is sensible from a practical point of
> view, but breaks Matlab compatibility).
> Another question is whether this syntactic sugar is worth creating
> another two octave_value classes (and thus increasing code bloat),
> especially when most of the code will have to ensure compatibility.
> 

Is the above just a diagonal sparse matrix stored in a different form. In
that case what does diags(v)*A give you? Improvements I'd suggest are

* Make diags flag the matrix type as diagonal if it is
* For the spare-dense multiply functions special case the diagonal scaling
case

This would pretty much implement the third option with little work and only
require the user to use sparse diagonal matrices instead for the scaling.
Its also not using tricks in the parser to get the wanted behavior and so
can't be fooled by d=diag(v);d*A as your other technique will be.

Cheers
David


-- 
View this message in context: 
http://www.nabble.com/compound-operators---what-next--tp17311996p17312512.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.