octave-maintainers
[Top][All Lists]
Advanced

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

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


From: David Bateman
Subject: Re: Moving code from octave-forge to octave [Was: polyderiv problem?]
Date: Thu, 24 Feb 2005 14:37:58 +0100
User-agent: Mozilla Thunderbird 0.8 (X11/20040923)

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..

Regards
David

--
David Bateman                                address@hidden
Motorola Labs - Paris +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax) 91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary



reply via email to

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