[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: deprecated functions
From: |
Jaroslav Hajek |
Subject: |
Re: deprecated functions |
Date: |
Thu, 5 Mar 2009 20:52:30 +0100 |
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
- Re: deprecated functions, (continued)
- 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, 2009/03/04
- 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 <=
- 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
- Re: deprecated functions, Jason Riedy, 2009/03/05
- Re: deprecated functions, Jason Riedy, 2009/03/04
- Re: deprecated functions, Jaroslav Hajek, 2009/03/04
- Re: deprecated functions, Jaroslav Hajek, 2009/03/04