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

[Jaroslav Hajek]

On Wed, Mar 4, 2009 at 8:58 PM, Jason Riedy <address@hidden> wrote:
> 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.
>

Maybe you're forgetting you work with development sources?


>> 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.
>

dmult never scaled from the right in any stable version and was
*never* intended neither documented to scale sparse matrices, which it
did in an inefficient manner. End of story.
I'm not insisting that dmult *must* go away; but if it goes back, it
will be reimplemented, and I would like you to give me an explanation
what are it's advantages compared to the trivial replacement
expressions.

as for spdiag, diag(sparse()) does the same job.

> 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.
>

Yeah, but not the best.

>>> 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.

Yeah, that's just a bug. Whoever deprecated splu missed this usage (or forgot).

> 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?
>

What's wrong with it? Besides, in current tip you get
P =

Permutation Matrix

   0   1   1
   1   0   1
   1   1   0


>>> 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.
>

What exactly are you trying to achieve? Remember that most sparse vs.
diag ops return a full matrix for compatibility with matlab, and
changing that would be a significant breach. You'd need to justify
such a change, and prepare for stiff opposition (I know what I'm
talking about :).  So I suggest you do the discussion first to avoid
doing something that won't be accepted.

> 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.
>

Having efficient diagonal -> sparse and permutation -> sparse would be nice.

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

That's what I did for the mx-op-defs and MArray-defs. I think there
was some speed up, but still not what I was hoping for. So I guess C++
is just slow, and we need to live with that.

regards


-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz