[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Kienzle
Subject: Re: Moving code from octave-forge to octave [Was: polyderiv problem?]
Date: Wed, 23 Feb 2005 19:04:28 -0500

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

| 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

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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]