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

[Paul Kienzle]

On Feb 23, 2005, at 10:51 AM, David Bateman wrote:

> John W. Eaton wrote:
>
> > On 10-Feb-2005, David Bateman <address@hidden> wrote:
> >
> > | Paul Kienzle wrote:
> > | | > Keeping stuff in m-files as much as possible really is 
> > attractive.
> >
> > Yes, I agree.  We should not convert everything to C++ just because we
> > can.
> >
> > | If only the existing octave version could be made faster....
> >
> > Probably it can be made faster.  It might be a lot of work, but so is
> > converting everything to C++ and then maintaining it.
> >
> > Also, how often are tril and triu used?  I only see one use of triu
> > and none of tril in Octave's scripts directory, and none of either in
> > another relatively large collection of .m files written by a
> > colleague.
> >
> > If it is really critical for some application that you have, then it
> > is easy enough to replace the .m version with your own .oct file.
> >
> > jwe
> Coming back to this... I don't necessarily agree that some functions 
> that can be implemented as m-files shouldn't be converted to oct-files 
> for speed reasons. The argument that my previous triu/tril file 
> couldn't handle user or new types is a valid criticism however, but 
> there is nothing to stop oct-files working directly on the 
> octave_values and producing the same results as the m-file... In fact 
> in the case of triu/tril the existing m-files won't work since there 
> is an assumption that after doing "retval =zeros(nr,nc)" we then have 
> the assignment function between the octave_matrix type and the 
> arbitrary type. This is certainly not always true, so the m-file file 
> is broken for user-types (cf fixed-point with 
> triu(fixed(2,7,randn(4,4))) ). Writing the code in an octave_file with 
> a generic code would in fact fix this problem.
>
> The attached oct-file is a proof-of-concept that generic functions 
> that operate of unknown types can equally be written in an oct-file...

The problem with oct-files is that they are more difficult to maintain.
Usually they have more code, and fewer people in our user base are
comfortable debugging them.

Personally, I would like to see most argument type checking and 
conversion
going on in m-files, and have a light foreign function interface that
can directly call C code with dense vectors.  That keeps the C easy and
allows octave to be fast.

- Paul