[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: Thu, 24 Feb 2005 19:01:38 -0500

On Feb 24, 2005, at 9:49 AM, David Bateman wrote:

Paul Kienzle wrote:

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?

Still no good for galois and fixed point types, since the class doesn't give enough information to determine the complete type (cf GF(2) vs GF(8)). Again, I believe that an example variable passed to the function with the correct type is the only way around such problems...

How do you save and load such beasts from files?

Does typeinfo give more complete information?

If the types really are not compatible, then the string names should not match.

Maybe class should return "GF(2)" if it is GF(2), and octave can pass the
extra info in the parentheses to the zeros constructor.

- Paul

reply via email to

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