This is the mail archive of the
gsl-discuss@sources.redhat.com
mailing list for the GSL project.
Re: package tensor
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