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

[Paul Kienzle]

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.

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.

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.

- Paul