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

[David Bateman]

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

Humm, needs some thought...

D.


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