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

[Paul Kienzle]

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.

- Paul