help-gsl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-gsl] Vector and matrix views


From: James Bergstra
Subject: Re: [Help-gsl] Vector and matrix views
Date: Wed, 7 Dec 2005 19:56:33 -0500
User-agent: Mutt/1.4.2.1i

Hi Dimitris,

I agree with you completely that there should be a better way. In the meantime,
remember that C has no private and public members :)

A gsl_vector struct has three important fields:

    v.data    ( pointer to data[0] )
    v.stride  ( gsl_vector_at(v,i) refers to v.data[i * v.stride] )
    v.size    ( gsl_vector_at(v,i) fails for i >= v.size )

as long as you feel like you can manage these fields, then vector functions that
don't free the underlying data should work as they should.  You do *not* need to
use gsl_vector_alloc and family, or use the views. To be extra-safe, set 
v.owner to
zero to encourage responsible methods not to dereference v.block.

Brian Gough may cringe at this abuse of the API, but it works for me...
The same trick works for matrix types.  Matrices have two sizes instead of one,
and the 'stride' between columns on the same row is always assumed to be 1, but
other than that, the things are analogous.  For some reason, a matrix stride
(from row to row) is in a field called 'tda'.

James Bergstra

On Thu, Dec 08, 2005 at 02:17:26AM +0200, Dimitris Papavasiliou wrote:
> Hi all,
> 
> I need to quickly and efficiently create a gsl vector/matrix from a C 
> array but doing something like
> 
> +====
> gsl_vector_view v_view;
> gsl_vector *v;
> 
> v_view = gsl_vector_view_from_array(array, n);
> v = &v_view.vector;
> +====
> 
> tends to get tedious and bloat functions where many vectors are 
> manipulated.  Also using &v_view.vector to refer to the vector is ugly 
> and makes to code less readable.
> 
> Would something like this work
> 
> +====
> gsl_vector v;  /* a struct, not a pointer */
> 
> v = gsl_vector_view_from_array(array, n).vector;
> +====
> 
> I know this looks ugly too but hidden behind a macro it would be ok.  
> Would this work correctly?  I've tried it and it seems to work but I'd 
> like to make sure.  If it works then maybe it would be useful as a macro 
> in GSL itself
> 
> #define gsl_vector_from_array(array, n) 
> gsl_vector_view_from_array((array), (n)).vector
> 
> and similarly for const, matrices, etc.
> 
> On a side note: why do views have a separate struct with only one 
> member?  I've read in an old message in the archive that this is so in 
> order to make const vectors work but I can't imagine how keeping a 
> struct with one member is any different than keeping the member itself.  
> If it is't too much trouble could someone please explain?
> 
> I'm asking because, if you use the GSL to do calculations with 
> matrices/vectors which need to be stored in C arrays (so that they can 
> be passed to opengl for example) keeping an extra struct for each 
> vector/matrix can be anoying in complex computations.  In fact this is 
> what kept me from using the GSL when I first discovered it half a year 
> ago.  Let me say though, after all that whining that I was otherwise 
> thrilled with it as this is a pretty amazing library design-wise and 
> even used its ODE solvers with no problems in a cloth simulation.
> 
> Dimitris P.
> 
> 
> _______________________________________________
> Help-gsl mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/help-gsl

-- 
james bergstra
http://www-etud.iro.umontreal.ca/~bergstrj





reply via email to

[Prev in Thread] Current Thread [Next in Thread]