octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: deprecated functions


From: John W. Eaton
Subject: Re: deprecated functions
Date: Wed, 4 Mar 2009 17:26:21 -0500

On  4-Mar-2009, Jason Riedy wrote:

| And John W. Eaton writes:
| > Maybe I'm slow, but what is the large impact of having diag x sparse
| > operations convert to full?  What does it break?  I guess I could use
| > some examples.
| 
| A typical use (for me) of diag * sparse is to rescale the matrix before
| solving a system with it.  Many sparse matrices from automatic systems
| (e.g. optimization problem builders) are horribly ill-scaled and appear
| to be ill-conditioned.  Rescaling the problem can greatly improve the
| solution.  The rescaling should have negligible cost.
| 
| For a direct method, if diag * sparse is full, you're lead to a full
| factorization and needlessly slow performance.  For an iterative method,
| making A dense makes A*x far, far more expensive than it should be.
| 
| Yes, code *could* contain an if sparse(...) test, but why?  What is the
| benefit of forcing code to care about structure when it's otherwise
| agnostic?

I guess my question wasn't clear.  I understand why it would be useful
to have sparse x diag operations preserve sparsity.  What I'm asking
is what would be the big problem with doing that?  How does it cause
significant compatibility problems.  I realize that if we made the
change so that

  diag (v) * sparse_matrix  -->  sparse in Octave, full in Matlab

that there would be a difference.  But exactly what would be
catastrophically bad about it?

After all, we currently have diag (v) producing a specialized matrix
type instead of a full matrix, so why is that not also as bad for
compatibility?  What makes the sparse x diag --> sparse worse?

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]