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

[Paul Kienzle]

On Feb 24, 2005, at 8:37 AM, David Bateman wrote:

> Paul Kienzle wrote:
>
> > 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.
>
> Try zeros(m,n,"galois") and see what it gives you..... This doesn't 
> and can't know all of the user types. Also for the case of a Galois 
> Field how would zeros(m,n,"galois") know whether your in GF(2) or 
> GF(2^M), etc or what the primitive polynomial is. This is why I 
> suggested that the only way to ensure the correct zeros matrix is 
> created, is to allow an object of the desired type to be passed. 
> Perhaps the correct syntax could be made to be something like 
> zeros(m,n,"auto",x), where the "auto" defines that the type should be 
> derived from the following arg..

Clearly zeros() is a constructor for the type so dispatch won't work
because the type doesn't yet exist to dispatch from.  If instead we
register the zeros() function when we register the class, then octave
can do the right thing.

Are there any other standard constructors that we need to consider?

- Paul