Re: GSoC ode15{i,s} - type conversion and approximation problems

[Carlo De Falco]

On 16 Jun 2016, at 17:25, Francesco Faccio <address@hidden> wrote:

> I would  like to ask you some suggestions regarding some problems on the 
> implementation.

Dear Francesco,

I see you are doing a lot of looping to copy that back and forth from 
Octave to sundials which is unnecessary.

In the case of dense matrices you can just copy the whole block of memory
at once using memcopy or std::copy. How the data of a dense matrix is stored
in sundials is described in the header sundials_direct.h:

--------------------8<--------------------
 * For DENSE matrices, the relevant fields in DlsMat are:
 *    type  = SUNDIALS_DENSE
 *    M     - number of rows
 *    N     - number of columns
 *    ldim  - leading dimension (ldim >= M)
 *    data  - pointer to a contiguous block of realtype variables
 *    ldata - length of the data array =ldim*N
 *    cols  - array of pointers. cols[j] points to the first element 
 *            of the j-th column of the matrix in the array data.
 *
 * The elements of a dense matrix are stored columnwise (i.e columns 
 * are stored one on top of the other in memory). 
 * If A is of type DlsMat, then the (i,j)th element of A (with 
 * 0 <= i < M and 0 <= j < N) is given by (A->data)[j*n+i]. 
--------------------8<--------------------

you can access a pointer to the data in an Octave Matrix object
via the fortran_vec() method:
http://octave.org/doxygen/4.0/d0/d26/classArray.html#a67b2e787997a741df610756815ed4f95


Anyway if you are looping through many elements of a matrix you should 
use the method xelem () instead of elem () to improve performance.

elem () introduces a lot of overhead to implement bounds checking
and copy-on-write semantics which we don't really need here.

HTH,
c.