Re: deprecated functions

[Jaroslav Hajek]

On Wed, Mar 4, 2009 at 10:39 PM, Jason Riedy <address@hidden> wrote:
> And Jaroslav Hajek writes:
>>> 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.
>
> My reason is that As = Dr * A * Dc should work without needing to be:
>  if issparse (A),
>    As = sparse (Dr) * A * sparse (Dc);
>  else
>    A = Dr * A * Dc;
>  endif
> Along with many other, similar tests that need sprinkled throughout to
> make dense code work with sparse matrices.
>
> That would be a competitive *advantage* for Octave, just like
> unwind_protect is.
>
> And for my colleagues, well, because Octave is so compatible with
> Matlab(TM), they don't think it's worth changing.  And the only
> place they really, really care about close compatibility is in
> plotting and GUIs, and Octave ain't there.
>
> I haven't convinced a *SINGLE* person to try Octave because it's
> compatible to Matlab(TM), even with the increase in license
> prices and the pain of using Matlab(TM) on a cluster.  The only
> ones I have convinced have come over for *differences*, places
> where Octave is superior.  The flexible native code interface is
> a major one.  Amazingly, double quotes are another, as is
> start-up speed (if not run over NFS).  Octaviz (VTK interface)
> and MPITB (MPI interface) have helped when I fail to mention
> similar Matlab(TM) packages...
>
> Being able to express linear algebra algorithms more clearly and
> concisely than in Matlab(TM) would be a useful difference.
>
> Are there any Matlab(TM)-using textbook examples that won't work
> if diagonal matrices keep sparse matrices sparse?  I really doubt
> it, and that's the only place where compatibility might be worth
> the stupidity.  I know compatibility brought in a short burst of
> serious funding, but I don't see that happening again.
>
> If Octave just wants to plod along after Matlab(TM), tell me, and
> I'll stop working on making diagonal matrices act sensibly.
>

I don't think we should copy Matlab's defects, and what you suggest is
of course sensible. The only reason I didn't do it when I was creating
diagonal matrices was the compatibility issue. I have a strong feeling
that we should do something like a ballot.

As for the work, I'd like to kindly ask you to first share your plans.
You see, actually enabling the behavior you ask for is almost as easy
as changing the default conversion of diagonal matrices to sparse
ones, then I think just about everything will immediatelly work
correctly, though not as efficiently as it could.
We should certainly specialize diag * sparse and diag \ sparse, and
probably also diag + sparse and diag - sparse (because we do so for
dense matrices), but it can, and should, be done incrementally.

I would like to reuse as much code as reasonably possible here.

cheers

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