Re: package tensor

[Jordi Burguet Castell <jordi dot burguet dot castell at cern dot ch>]

Hi again,

finally I decided to get rid of varargs and switch to arrays. The fact that 
you had to do it by hand for your wrapper convinced me. The old version with 
varargs is tagged rel-0-9-varargs. The new version with (const size_t *) is 
tagged rel-0-95-array.

The new version changes the order of argumens in function gsl_tensor_set(), 
and now follows the example of gsl/matrix. Before it was not possible because 
"..." had to be the last argument.

The main difference between tensors and matrices and vectors is that there are 
no tensor views. I am not sure of their utility for tensors, or how to 
implement them. However, I have added two functions that may be useful for 
such things: gsl_tensor_2matrix() and _2vector(), which create a (square) 
matrix from a rank=2 tensor and a vector from a rank=1 tensor respectivelly.

So Yoshiki, sorry for changing the interface! Now I guess it should be stable 
and probably easier to work with for your wrapper.


>   The class GSL::Tensor wraps the struct gsl_tensor, but now
> I am considering to use an "upper" struct, like
>   struct rbgsl_tensor {
>     gsl_tensor *t;
>     gsl_vector_uint *indices;
>   };
> and to create gsl_tensor and a vector for indices simultaneously
> by the constructor GSL::Tensor.alloc(), to prevent from
> allocating/freeing vectors in every call.

It does make sense. But instead of gsl_vector_uint I suggest using an array of 
size_t, which is what I use now and what you correctly pointed out that 
position2index() gives back (following gsl/matrix conventions).


>   How do you plan in future development?

I don't really plan to extend it, just to fix bugs if found and satisfy 
requests if reasonable. I think all the basic tensor stuff is there. 
Specially now that I've switched to arrays for passing indices.

However, I might continue with:
* adding a new type where for each index there is a different dimension (so 
you can do tensors of NxMxRXS elements, say "grids", but of course no 
switch_index() tensor_product() nor tensor_contract() there)
* adding complex numbers and operations on those tensors
* implementing views
but it depends much on the interest people have for tensors in general and 
those things in particular.


>   C varargs would bring some 
> troubles, but it is far easy to use in writing C code (not for
> wrappers) as gsl_tensor_get(t, i, j, k, ...), than to give a vector
> storing indices as
>     v->data[0] = i; v->data[1] = j; v->data[2] = k;, .....
>     gsl_tensor_get(t, v);
> I guess that's why you use varargs, and I prefer to it than uint*.

Indeed. Now with arrays the syntax in C is clumsier (you just have to compare 
the two test_source.c versions); I'd rather use them through some higher 
level language like Ruby!

Cheers,
Jordi