Re: Moving code from octave-forge to octave [Was: polyderiv problem?]

[David Bateman]

Paul Kienzle wrote:

> On Feb 10, 2005, at 5:07 AM, David Bateman wrote:
>
> > Paul Kienzle wrote:
> >
> > > The correct solution is to fix whatever is making octave slow 
> > > (probably memory management) rather than coding everything in C++.  
> > > triu/tril could be using whatever banded matrix types you have been 
> > > working on.
> > Ok, see the attached version against the sparse_merge branch that 
> > treats all types, even the banded types I'm working on.
>
> That's a lot of code for a simple function. And it won't work for 
> fixed point or symbolic types since they are not part of the octave core.

Not that much, as the core is a macro repeated N times.

> Using type-based dispatch doesn't help since the function still needs 
> to be written for every type.
>
> Putting it in the matrix class doesn't help since Ftril will still 
> need to extract the value to operate on it and so will need the same 
> switch statement.

True, this version would work on user types, and those would need a 
dispatched version, which is less elegant.

> Putting it in octave_value has some merit since at least it would 
> automatically handle each new fundamental type which came its way.  
> This would require a lot of changes to octave_value though since all 
> the structural information (nDArray vs. sparse vs. scalar) would have 
> to move into it.  And any new functions would need to be added 
> directly to the octave_value class which pretty much kills 3rd party 
> extensions.  This still doesn't address code bloat though it at least 
> allows the option of only loading the types you need.
>
> Keeping stuff in m-files as much as possible really is attractive.
If only the existing octave version could be made faster....

D.

--
David Bateman                                address@hidden
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary