help-gsl
[Top][All Lists]
Advanced

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

Re: [Help-gsl] Contents Help-gsl Digest, Vol 103, Issue 4 (Vector Views


From: Gideon Simpson
Subject: Re: [Help-gsl] Contents Help-gsl Digest, Vol 103, Issue 4 (Vector Views)
Date: Mon, 7 May 2012 12:04:28 -0500

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?

-gideon

On May 7, 2012, at 11:00 AM, address@hidden wrote:

> Send Help-gsl mailing list submissions to
>       address@hidden
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>       https://lists.gnu.org/mailman/listinfo/help-gsl
> or, via email, send a message with subject or body 'help' to
>       address@hidden
> 
> You can reach the person managing the list at
>       address@hidden
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Help-gsl digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: vector views (Jonathan Taylor)
>   2. Re: 64-bit GSL for Windows 64-bit system (Lei Shang)
>   3. Re: design philosophy (Jerome BENOIT)
>   4. Re: vector views (Rhys Ulerich)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 7 May 2012 09:10:53 +0100
> From: Jonathan Taylor <address@hidden>
> To: address@hidden
> Subject: Re: [Help-gsl] vector views
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
> 
>>> Just wondering if someone can help me out with using vector views.  I have 
>>> a set of N complex numbers which I am storing in a 2*N size gsl_vector.  I 
>>> am using this because I am looking for the solution of a nonlinear system, 
>>> and, to the best of my knowledge, the multidimensional root finding 
>>> algorithms only take functions with gsl_vector arguments.
>>> 
>>> So here's my question, does anyone have any tips on how to set up vector 
>>> views so that I have pointers available that logically map to the real and 
>>> imaginary portions of the vector?  I.e.,  I want
>>> 
>>> gsl_vector * z // Size 2*N
>>> gsl_vector * a // Size N, a= Re z
>>> gsl_vector * b// Size N, b= Im z
>> 
>> Vector views are 1D subsets of matrices -- e.g. if you wanted to refer to a 
>> given column of a matrix by a different, more convenient name. I'm working 
>> from memory here, but I'm not certain there are any functions to create a 
>> vector view with a subvector. I would have guessed you wanted a z = 2*N 
>> matrix, then create vector views from each of the two rows or columns to 
>> hold the real and imaginary channels in vector(like) structures. If you want 
>> to handle the vector view (vv) as an actual vector, which appears to be the 
>> case, you have use &vv.vector.
> 
> You can actually create vector views of subvectors:
> http://www.gnu.org/software/gsl/manual/html_node/Vector-views.html
> and as John says you can use &vv.vector in all the same places you would use 
> a gsl_vector*. I would have thought his suggestion of a 2xN matrix might make 
> more logical sense for your problem, though. If you do prefer a vector, you 
> might want to give a little thought to whether an interleaved or separated 
> arrangement in your vector will be more efficient and/or cause you less 
> hassle in the long run (i.e. whether you store Re(z1), Im(z1), Re(z2), Im(z2) 
> or alternatively Re(z1), Re(z2)..., Im(z1), Im(z2)...)
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Mon, 7 May 2012 18:19:50 +1000
> From: Lei Shang <address@hidden>
> To: Sisyphus <address@hidden>
> Cc: help-gsl <address@hidden>
> Subject: Re: [Help-gsl] 64-bit GSL for Windows 64-bit system
> Message-ID:
>       <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Thanks, Rob. I fully installed the latest MinGW (20111118), which includes
> MSYS. But it still failed. I may try again tonight.
> My system is 64-bit Windows 7, is that possible you directly give your
> precompiled GSL file (libgsl.dll and libgslcblas.dll) to me if you have the
> similar architecture.
> 
> I know few about cross-compilation under Cygwin. I may have a look.
> 
> Thanks anyway.
> 
> Lei
> 
> 
> 2012/5/7 Sisyphus <address@hidden>
> 
>> 
>> ----- Original Message ----- From: "Lei Shang" <address@hidden>
>> To: "Feng Chen" <address@hidden>
>> Cc: "help-gsl" <address@hidden>
>> Sent: Monday, May 07, 2012 5:24 PM
>> Subject: Re: [Help-gsl] 64-bit GSL for Windows 64-bit system
>> 
>> 
>> 
>> Thanks. I have tried Cygwin and it works to compile 64-bit GSL library for
>>> Windows.
>>> But the problem is the generated GSL library only works for Cygwin. What I
>>> need is a 64-bit library (libgsl.dll) working for Matlab MEX.
>>> Any ideas?
>>> 
>> 
>> Do you have the msys shell ?
>> If so, it's essentially the same as building for Cygwin - something like:
>> 
>> ./configure --disable-static --enable-shared --prefix=C:/destination
>> 
>> Msys is freely available if you don't already have it.
>> 
>> I use the msys shell that shipped with my 32-bit MinGW download
>> (mingw-get-inst-20110802.exe). It's just a matter of altering the msys
>> shell's path so that it finds the 64-bit compiler instead of the 32-bit
>> one. (It builds gsl fine for me.)
>> 
>> I believe you could also use Cygwin to cross-compile for 64-bit Windows -
>> but it's something I haven't done. (You could ask for details about that on
>> the Cygwin mailing list if you wanted to go down that path.)
>> 
>> See how you go, and ket us know if you require additional help.
>> 
>> Cheers,
>> Rob
>> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Mon, 07 May 2012 13:32:13 +0200
> From: Jerome BENOIT <address@hidden>
> To: address@hidden
> Subject: Re: [Help-gsl] design philosophy
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Hello:
> 
> it could be also for historical reasons:
> some part of the code were be written at the early stage of GSL.
> 
> On 06/05/12 20:22, Rhys Ulerich wrote:
>> Hi Gideon,
>> 
>>> I'm working on a project that involves both numerical integration of a 
>>> system of ODEs and the solution of nonlinear systems of equations, and I 
>>> was wondering if there was a reason that the interfaces were not better 
>>> unified.  In particular, the ODE routines take, as arguments, double 
>>> arrays, while the nonlinear solvers use the gsl_vector data structure.  
>>> It's easy enough to map from one to the other, but I was wondering, why not 
>>> have more consistency?
>> 
>> From what I have gathered by lurking on the mailing list and digging
>> through documentation, for logic which could be isolated from the
>> gsl_vector classes, double* arrays were preferred so that folks could
>> copy'n'paste the code without needing all of the GSL.  It is likely
>> the case that the nonlinear solvers require enough GSL machinery that
>> they could not simply be ripped out.
>> 
>> - Rhys
>> 
> 
> Jerome
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Mon, 7 May 2012 08:48:44 -0500
> From: Rhys Ulerich <address@hidden>
> To: Gideon Simpson <address@hidden>
> Cc: address@hidden
> Subject: Re: [Help-gsl] vector views
> Message-ID:
>       <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
> 
>> Just wondering if someone can help me out with using vector views.
>> I have a set of N complex numbers which I am storing in a 2*N size 
>> gsl_vector.
>> ...
>> So here's my question, does anyone have any tips on how to set up vector
>> views so that I have pointers available that logically map to the real and 
>> imaginary
>> portions of the vector?
> 
> I'd create a complex-valued vector of length N using
> gsl_vector_complex_alloc (say "z"), then use gsl_vector_view to create
> a real-valued view of length 2N from the data (say "zd"), then use
> gsl_vector_subvector_with_stride to create strided views for the real
> and imaginary parts.  As you'd expect the real-valued offset will be
> zero with stride two and the imaginary-valued offset is one with
> stride two.  The views are documented well at
> http://www.gnu.org/software/gsl/manual/html_node/Vector-views.html.
> The complex-valued vector details are analogous and are declared
> within <gsl/gsl_vector_complex_double.h> in a readable fashion.
> 
> You could, of course, skip my suggestion to start with a
> complex-valued vector and simply start with the 2*N gsl_vector.  I'm
> guessing having a complex-valued vector will be handy for other
> reasons in your code.
> 
> Hope that helps,
> Rhys
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> Help-gsl mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/help-gsl
> 
> 
> End of Help-gsl Digest, Vol 103, Issue 4
> ****************************************




reply via email to

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