Diagonal v. sparse matrices [was Re: deprecated functions]

[Jason Riedy]

And John W. Eaton writes:
> How does it "spew".  Any warning about a particular deprecated
> function should only be issued at most once per session (unless you
> clear the deprecated function, in which case the warning should be
> printed again the first time you run the function again after clearing
> it).

My test cases are all individual sessions.  As are all the jobs launched
in batch queues.  A batch run involves hundreds to thousands of
sessions.  These messages made diffs quite loud...  (I highlight
warnings and errors.)

> warning off Octave:deprecated-function

I'll use that, I guess, once I trace down all the "deprecated" functions
that now are completely different.  I'd prefer the functions not be
deprecated until the new versions work.

> Jaroslav already explained his reason for reverting the behavior.

True.  This really is in the context of applying scaling factors to a
diagonal matrix.  I can no longer use either dmult or spdiag.  The
former no longer applies scaling factors on the right, and the latter no
longer returns a sparse matrix.

Hence the less than useful comment.  Adding diagonal matrices has
*removed* significant sparse functionality.  After switching away from
dmult, I suddenly started running out of memory.  The only clue was the
deprecation notice in spdiag, and that doesn't say spdiag has changed...

I suppose the shortest path to a fix is to revert spdiag.

>> splu is also spewing now (used in condest), but I assume that's
>> correctly dispatched to a function that returns the column permutation
>> in the sparse case...  I haven't checked yet.
>
> Spewing how?  Care to give an example?

Same thing.  splu has been deprecated, so all of my scripts and tests
that call condest complain.  It appears that lu is now a complete
superset of splu, so that patch will come along soon.

With the improved permutation matrices, it *may* be nice of lu to return
a trivial column permutation when called on dense matrices.

BTW, [L,U,P] = lu(eye(3)) returns a P that is displayed as
   0   1   1
   1   0   1
   1   1   0
Is that output style intentional?

>> Looking at the error messages from my first attempt, it'll be a while.
>
> What's the problem?  Maybe if you reported the trouble you are having,
> or posted your code, someone could help you.

Figuring out which macros need called where and with what arguments.
I'm cheating and just converting the DiagMatrix to a SparseMatrix and
calling the other function.  For example,
  #define SPARSE_DMSM_BIN_OP_1(R, F, OP, M1, M2)        \
    R                                                   \
    F (const M1& m1, const M2& m2)                      \
    {                                                   \
      M2 sm1 (m1);                                      \
      R r (F (sm1, m2));                                \
      return r;                                         \
    }

My previous problem was calling sm1 OP m2 rather than F (sm1, m2).

Now I'm waiting for the build to tell me what I've done wrong with
op-dm-sm.cc, et al. in src/OPERATORS.  Then I'll start adding tests and
may return with questions.

After all this is working, I'll worry about using the diagonal matrices
directly.

And then I may look into making permutation matrices sparse, but I don't
have an immediate need for that.

Splitting Sparse-op-defs.h into separate files to make the build faster
is a separate project completely...

Jason