This is the mail archive of the gsl-discuss@sources.redhat.com mailing list for the GSL project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]