Re: deprecated functions

[Jaroslav Hajek]

On Thu, Mar 5, 2009 at 7:51 PM, Jason Riedy <address@hidden> wrote:
> And Jaroslav Hajek writes:
>> 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.
>
> Sure does.  And as you said, that's the easy step.  It's a small,
> localized patch; I'll send it along shortly.
>
>> 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.
>
> My first target will be diag * sparse and sparse * diag.  I had
> tried to jump in whole-hog, but somehow DEFBINOP_OP spun off into
> an infinite recursion.  But that was the sketch last night, and
> now I'm heading in the more sensible way.
>

OK, nice. This is not going to be in 3.2, so there's no need to hurry.

>> I would like to reuse as much code as reasonably possible here.
>
> Oh, I would like to see many things, particularly templates
> rather than macros and a sprinkling of OpenMP.  But that will
> have to be evolutionary as well.  I'll post what I have once
> something sensible works.
>

Back a few months I would strongly agree, but I am now a little less
certain. I used a heavily templatized code for optimizing the integer
operations in oct-inttypes.h. The current implementation is surely
better than the old one (amongst others it avoids the pointless
comparisons warnings) but it is my impression that sources #including
oct-inttypes.h compile somewhat more slowly. OTOH, mixing templates
with macros has worked well for me when optimizing stuff in
mx-inlines.cc.
I think Octave compiles relatively slowly now, and I would not like it
to get even slower. But maybe that's really only an issue when lots of
templates used in headers. I know macros have a bunch of other
drawbacks, so I agree with moving more executive code to templates
(macros for declarative code still seem like the best solution to me).
I wanted to simplify the array class design in liboctave (reduce
number of classes), so maybe such changes will best go hand in hand.
As of now, however, I guess it's best if the operations are
implemented into the existing machinery (i.e. Sparse-op-defs).

regards

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