[PATCH 0 of 4] Implement basic sparse op diag and diag op sparse support.

[Jason Riedy]

And Jaroslav Hajek writes:
> I have applied all Jason's changes to my test repository, fixed the
> diagonal * sparse problems, removed the checks for single-element
> diagonal matrices and made a few other adjustments (such as not
> introducing namespaces yet).

Thanks!  I'll check on it when I have a sensible network connection
tomorrow.  My work became hung up when I realized scalar double *
complex diagonal was becoming double sparse * complex diagonal when
performed explicitly, which is another reason why the single-element
checks should be avoided.

I became lost trying to add scalar double * complex diagonal[1].  ;)

At some point, the scalar->matrix constructors in liboctave should be
marked as explicit.  That may flush out some surprising things that just
happen to work...

> These changes do not yet modify the default conversion of diagonal
> matrices - that would be the most incompatible change, probably, and
> maybe should be further discussed.

I still need to revisit your comments on the permutation matrices.
Thanks for looking at all this!

With the basic sparse & diag (and sparse & permutation) ops, I don't see
why either diag or sparse should fall back to sparse.  And the
discussion of the "right" thing to do with diag .* sparse or sparse ./
diag definitely is future work; there are at least two "right" things,
depending on the use.

Jason

Footnotes: 
[1]  For one reason why that might be useful, consider
        1 * diag ([1 + I() * Inf, 1])
Converting the scalar 1 to a complex produces NaNs.  For further
examples and reasons, see
  W. Kahan and J.W. Thomas
  Augmenting a Programming Language with Complex Arithmetic
  http://www.eecs.berkeley.edu/Pubs/TechRpts/1992/6127.html
And yes, there's another whole discussion about Infs in complex
arithmetic that leads back to a compromise made in the 70s. ;)