[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: deprecated functions
From: |
Jaroslav Hajek |
Subject: |
Re: deprecated functions |
Date: |
Wed, 4 Mar 2009 21:59:41 +0100 |
On Wed, Mar 4, 2009 at 9:33 PM, Jason Riedy <address@hidden> wrote:
> And Jaroslav Hajek writes:
>> diag(sparse(vector)) * sparse matrix, obviously. It will be less
>> efficient than with dense matrices, but will work.
>
> But then all code that *might* be called with sparse matrices must use
> diag(sparse(vector)). If it doesn't, it might suddenly blow out memory
> when called with a sparse matrix. Why is that preferable to making diag
> * sparse * diag work?
>
> Matlab(TM) made yet another stupid, stupid decision. Why is Octave
> bound to all of them? It Matlab(TM) were to change (incompatibly,
> again), they'd trumpet it as an improvement.
>
> It's better if *more* code can work transparently with sparse matrices,
> not less.
>
> Yes, there are odd problems with elementwise exceptional operations, but
> similar problems exist with complex numbers in many programming
> environments, too. You don't even want to know how long we spent
> arguing what max(NaN, Inf) should be for IEEE-754r. It's not worth
> bothering too much over those without driving examples.
>
>> I believe the sparse scaling of dmult was an unintended side effect,
>> because constructing a temporary dense matrix of the same size is
>> certainly a *very* inefficient way to do the scaling.
>
> For whatever reason, it wasn't blowing memory, but now something is.
Yes, it was. Only not that much, I suppose.
> Using dmult to scale a sparse matrix isn't in the expensive part of my
> tests, so I never noticed. I had never even noticed it was a function
> file and not compiled... Older code had dmult(vector, matrix); I just
> tried dmult(matrix, vector), and it worked.
That was, in fact, another potential danger of dmult that you probably
were not aware of.
What should "dmult (row vector, column vector)" return? Is the default
left or right scaling?
diag(A) * B is unambiguous.
>
> But really I don't care about dmult. It was a short, relatively clear
> way to say what I meant. Having diag * sparse be sparse is much, much
> better.
>
Definitely, if you ignore Matlab, it is. But it's just not that easily
possible. I recently needed (successfully, I hope) to justify a
compatibility breakage with much smaller impact, and it was really a
long discussion. And it's good that it's so. I agree with John and
David and others that Octave's compatibility with Matlab is a big plus
for many users, including some of my colleagues. One day, Octave may
throw away the burden of Matlab compatibility. But I see that day
still being far off.
cheers
--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
- Re: Diagonal v. sparse matrices, (continued)
- Re: Diagonal v. sparse matrices, Jason Riedy, 2009/03/04
- Re: Diagonal v. sparse matrices, Jaroslav Hajek, 2009/03/04
- Re: Diagonal v. sparse matrices, Jaroslav Hajek, 2009/03/04
- Re: deprecated functions, Jaroslav Hajek, 2009/03/04
- Re: deprecated functions, John W. Eaton, 2009/03/04
- Re: deprecated functions, Jaroslav Hajek, 2009/03/04
- Re: deprecated functions, John W. Eaton, 2009/03/04
- Re: deprecated functions, Jaroslav Hajek, 2009/03/04
- Re: deprecated functions, John W. Eaton, 2009/03/04
- Re: deprecated functions, Jason Riedy, 2009/03/04
- Re: deprecated functions,
Jaroslav Hajek <=
- Re: deprecated functions, Jason Riedy, 2009/03/04
- Re: deprecated functions, Jaroslav Hajek, 2009/03/05
- Re: deprecated functions, John W. Eaton, 2009/03/05
- Re: deprecated functions, Jaroslav Hajek, 2009/03/05
- Re: deprecated functions, Jason Riedy, 2009/03/05
- Re: deprecated functions, Jaroslav Hajek, 2009/03/05
- Re: deprecated functions, John W. Eaton, 2009/03/04
- Re: deprecated functions, Jason Riedy, 2009/03/04
- Re: deprecated functions, John W. Eaton, 2009/03/04
- Re: deprecated functions, Jaroslav Hajek, 2009/03/05