This is the mail archive of the
gsl-discuss@sources.redhat.com
mailing list for the GSL project.
Re: Two suggestions...
On Wed, 2003-06-11 at 12:16, Brian Gough wrote:
> Robert G. Brown writes:
> > a) In relation to the recent discussion on multidimensional arrays,
> > what about adding gsl_tensor? Something like:
> >
> > typedef struct
> > {
> > size_t dim;
> > size_t stride;
> > size_t *size;
> > size_t *lind;
> > void * data;
> > gsl_block * block;
> > int owner;
> > } gsl_tensor;
>
> I agree that this is the right way to define a tensor object in
> principle.
>
> My concern about tensors is that it's difficult to do anything with
> the higher indices because all the blas/lapack routines only work for
> the last two indices.
>
> So it doesn't seem possible to create tensor views, which is part of
> the usefulness of the vectors and matrices.
I think his main point (please correct me if I'm missing it)
is that this way you have a simple "view" scheme for switching
between vectors and matrices. The example of calling the ODE solver
with an underlying matrix argument is a good one, and it highlights
the issue.
Of course a tensor mechanism is more general than this, but
if the main motivation is to have a uniform interface available
for vectors and matrices, then it is an important idea.
We should consider doing something about this. I think there are
two choices:
1) create some hack which allows switching objects between
vectors and matrices, as a kind of special case
2) create a tensor interface, as Robert suggests
I don't see any reason to prefer the first over the second, so why
not consider tensors? Anyway, I don't think they would create any
problems or require any changes to the current interfaces.
Probably requires some fiddling under the hood if we want to
do it right though...
Also, I thought the comment about vectors of random numbers
was probably correct; it might be a bit tedious to add a
vector version of the rng functions, but it seems like
that's the least we can do, given all the good work that
has already gone into that library component.
--
Gerard Jungman <jungman@lanl.gov>
Los Alamos National Laboratory