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]

Re: gsl Development Query


Randall Judd wrote:

> I don't attach VSIPL blocks to GSL views.
> The idea is to associate (a word I prefer to attach)
> VSIPL blocks with GSL blocks (not views).
> Then define VSIPL vector and/or matrix views
> which map the block data space
> the same way that the GSL views map the GSL blocks data space.

A VSIPL block is like a C++ valarray.
The are both pure abstractions.
You can read what Kent Budge (kgbudge@valinor.sandia.gov)
has to say about valarray in his article
"Re: OONSTD: to early for standards?" at

	http://www.oonumerics.org/oon/oonstd/archive/0018.html

Both the VSIPL block and the C++ valarray
give the application programmer the "illusion"
that the underlying data array
is a contiguous block of real numbers
regardless of how they are actually stored in memory.
The C++ compiler may actually conspire
with the operating system and the computer architecture
to create this illusion for application programmers
who use valarray and return a "pointer" to an element
in a valarray
The ANSI C compiler is not expected to participate
in this illusion for VSIPL block objects.
The actual data representation of VSIPL block objects
is hidden from the application programmer
and, in general, elements can only be accessed
through VSIPL functions.

A GSL block isn't abstract at all.
It is defined to be

        struct gsl_block_struct {
          size_t size;
          double* data;
          };
        
        typedef struct gsl_block_struct gsl_block;

Aplication programmers are permitted to access
the double* data member directly and they are guaranteed that
they can always obtain a pointer to the underlying data array.
This means that the GSL can never distribute the data array
among the nodes of a multiprocessor system for example.

> As I understand it, your GSL block contains some data space.
> Then you slice this data space up.
> The first of your vector views creates
> the block, data space, and a vector.

All this does is to combine two VSIPL operations.
The first vector object "owns" the block.
The block should never be destroyed
until just before the owner is destroyed.

> The vector view contains a pointer to the block
> plus a pointer to the beginning of the data.
> When you take of subview of the vector,
> you set the block pointer to NULL,

This is just a precaution to help ensure
that the block is never destroyed
until just before the owner is destroyed.

> get a pointer to the beginning of the subviews data space

Essentially, they just precompute vector.data = block.data + offset
They could obtain the offset = vector.data - block.data
if they hadn't discarded the pointer to the block.
It's too bad really.  If they had retained the pointer to the block,
they could have used it to help determine
whether source and destination views overlap or not.

> and then set the attributes of the subview
> to the proper stride and length for the new vector
> which must not exceed the data space of the block.
> 
> In VSIPL every view contains a pointer to the block.
> The block contains the entire possible data space.
> For a GSL vector view attached to a block,
> the view contains a pointer to the beginning of data,
> a length equal to the data space length,
> and a stride equal to one.
> The corresponding VSIPL vector view contains
> an offset of zero, a stride of one
> and a length equal to the length of the block.
> 
> So, when I create a block,
> I would want the block to encompass the entire GSL block.
> 
> Now I could create a new block to do the GSL subview,
> but the new block would encompass some of the same data space
> as the previous VSIPL block.
> This would be an error from VSIPL's point of view.
> What I do in VSIPL is set an offset into the data space
> so my subview points to the same data space as the GSL subview.
> Then the stride and length would be the same as GSL.

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