
From:  David Bateman 
Subject:  Re: Moving code from octaveforge to octave [Was: polyderiv problem?] 
Date:  Thu, 24 Feb 2005 10:31:18 +0100 
Useragent:  Mozilla Thunderbird 0.8 (X11/20040923) 
Paul Kienzle wrote:
The problem with octfiles 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 conversiongoing on in mfiles, 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 3D matrix of zeros or a 2D matrix of the same type as "2"......
Humm, needs some thought... D.  David Bateman address@hiddenMotorola Labs  Paris +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax) 91193 GifSurYvette FRANCE
The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary
[Prev in Thread]  Current Thread  [Next in Thread] 