On Feb 24, 2005, at 4:31 AM, David Bateman wrote:
Paul Kienzle wrote:
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
Unfortunately, in the case I show th etype checking for arbitrary
user types can't be done since
the current assumption of have retval=zeros(nr,nc), and then filling
it in with assignments makes the assumption that there is an
assignment defined for octave_matrix to an arbitrary type. This is
not the case, the only other way to treat this is if something like
"retval=x([])(1:nr,1:nc)" could be made to convert the input matrix
x to a zero size matrix then the second indexing be made to do a
resize_and_fill to the right size find with zeros of the correct
type. The alternative is that the zeros function could be adapted so
that "zeros(nr,nc,x)" would return a zero sized matrix of the same
type as x, the question is then is "zeros(2,2,2)" interpreted as a
3-D matrix of zeros or a 2-D matrix of the same type as "2"......
zeros(m,n,"typename"), or in the triu case, zeros(m,n,class(X)).
This avoids the ambiguity and bonus it is already implemented.