[Top][All Lists]

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

Re: [Help-gsl] Nature of gsl_vector_view [was "Re: Contents Help-gsl Dig

From: Gideon Simpson
Subject: Re: [Help-gsl] Nature of gsl_vector_view [was "Re: Contents Help-gsl Digest, Vol 103, Issue 4 (Vector Views)"]
Date: Mon, 7 May 2012 12:30:05 -0500

On May 7, 2012, at 12:22 PM, Rhys Ulerich wrote:

> Hi Gideon,
> First off, it's helpful to have a useful subject rather than sending a
> message to the list simply by hitting Reply on a digest.  If you're
> unsure how to add details or more questions to your earlier "vector
> views" thread, one easy way is to Reply to yourself and CC
> address@hidden  That bit of tedium helps to keep the mail archives
> cleaner for people who like to search them.

Sorry about that.

>> I remain  a little unclear about what the gsl_vector_view object is.  Right 
>> now, I have a code snippet like this:
>> gsl_vector * y;
>>  y = gsl_vector_calloc(2*N);
>>  gsl_vector_view  yreal = gsl_vector_subvector(y, 0, N);
>>  gsl_vector_view  yimag = gsl_vector_subvector(y, N, N);
>>  for(i = 0; i < p->N; i++){
>>    b= cexp( _Complex_I * .25 * M_PI * i); // Using complex.h to handle 
>> complex numbers
>>    gsl_vector_set(&yreal.vector, i, creal(b));
>>    gsl_vector_set(&yimag.vector, i, cimag(b));
>>    printf(" y[%i] = %g, y[%i+N] = %g\n", i, gsl_vector_get(y, i),
>>           gsl_vector_get(y, i+N));
>>  }
>> What's unclear to me is what the gsl_vector_view structure is how
>> the structure handles memory.  I see that it encapsulates a gsl_vector 
>> object,
>> but does that structure just get the necessary pointer information?
> If you stare a bit at
> you'll
> see that a gsl_vector, among other things, contains an 'owner' member.
> In your example, y.owner is true so that if you deallocated y, it
> would know to deallocate y.block as well.
> A gsl_vector_view contains a gsl_vector member named member.  In the
> case of your yreal declaration, the line
>>  gsl_vector_view  yreal = gsl_vector_subvector(y, 0, N);
> simply copies the details from y into a temporary setting owner = 0
> along the way.  The compiler copies the temporary into yreal.  Then,
> later, when you pass &yreal.vector to gsl_vector_set you're literally
> passing a gsl_vector* which does not own but which knows
>'s value.
> If you're not deallocating y in your real code, definitely do so.
> Hope that helps,
> Rhys

Yes, I am deallocating y at the end.  I guess the question I'm really asking 
is, from a performance standpoint, is it bad to be using a lot of vector views 
to mask the data?  It enhances the clarity of the code, but is having many 
instances of the vector views problematic, from a memory usage point of view?

reply via email to

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