[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
> http://www.gnu.org/software/gsl/manual/html_node/Vectors.html 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 y.data but which knows
> y.data'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?