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:
> 
> VSIPL 1.0 is actually final now. It is available on the Documents page of
> the VSIPL site. On that page you will find something called, I think, "The
> basics requirements document". You might want to read that instead.

Yes, I just read it. It's marked "DRAFT 0.6", but I suppose I
should ignore that. There are also the "Core" and "Core Lite" documents,
which seem to be just tables of types and function names.

Anyway, as you say, it certainly seems like there is
nothing to prevent you from interfacing with GSL in
a natural way. I'm not even sure what we could do
to screw that up. We're just a little closer to
the underlying memory, which, I think, is natural
for our purposes.


> First of all in VSIPL a view is always bound to a block. The blocks in GSL
> just seem to be a place to keep your memory storage until your ready to
> destroy it. In VSIPL blocks are more important. To find the begining of
> your view in GSL you store a pointer to the beginning of data. In VSIPL we
> store an offset into the block. The vendor may do other stuff under the
> covers, but what the user sees is an offset.

I understand. Your blocks are already at a higher level
of abstraction, whereas ours really serve at the lowest
level, for basic heap management. Again, no problems.
I think.


> The vendor has a complete type definition,
> of course, but he does not give that to the user. What the user gets is a
> set of VSIPL defined functions to create and manipulate the block. "Views"
> (vector views, matrix views) on the block are treated the same way.

Maybe I should say explicitly that I don't think we should
expose things like the gsl_block attributes directly either.
The only sense in which we do is that the struct is there
in the header file. But I have always felt that this is
just a matter of style in C; for instance, I can go look
up lots of things in the standard C header files which I would
never rely on in an application program.

As you say, we're writing a library, not a specification.
So the struct defs have to go somewhere. The only reason
I make this obvious statement is because it seems to be
one of those things that Tisdale is ranting about (at
least as far as I understand anything he says).


> What VSIPL does is define a blockbind function. What blockbind does is to
> associate some regular memory with a VSIPL block. Then both VSIPL and the
> user can get to that memory. However VSIPL insists on owning any memory it
> might use, so we added functions to admit the block (and memory) to VSIPL
> and a release function to give ownership of the data back to the user.
> Admit and release are important. VSIPL does not necessarily use the user
> memory in the expected way. It may not use it at all. The purpose of admit
> and release is to force data consistency between the block and the memory
> during a state transition.

Ok.


> So if you wanted a gsl vector, and a vsipl vector on the same data space
> you could do (I don't know much about gsl so there may be an error here)
> 
> gsl_vector *a_gsl_vview = gsl_vector_alloc(N);
> vsip_block_d *a_vsipl_block = vsip_blockbind_d(
>         a_gsl_vview->block->data, N, VSIP_MEM_NONE);
> vsip_vview_d *a_vsipl_vview = vsip_vbind_d(a_vsipl_block, 0, 1 , N);

A minor point, but maybe important. Why not use
the gsl_vector_ptr() method to get the pointer
to the underlying type, rather than "a_gsl_vview->block->data"?
Anyway, that is supposed to provide the necessary abstraction
away from the explicit struct attributes.
[Ahah. I see that this is the point, from your
 comments below. Ok, let's move on to that then...]

[Aside to Brian: Is the damn definition for gsl_vector_ptr() missing?
 I can't find the implementation anywhere...]


> NOTE: It is not a mistake when I attach VSIPL to the data in the GSL block
> instead of the GSL view. You don't want the same data segment attached to
> two different VSIPL blocks. This is one of the problems I have with the way
> GSL did this, but it appears that you can with a little care create
> matching gsl and VSIPL views for any number of subviews on the original
> data set.

Ok. This is the part I need to understand. Let me state what I
understand and you can tell me if I am missing the point. The problem
is that you would like to attach VSIPL blocks to GSL views,
but the semantics do not match because GSL views might overlap,
and VSIPL blocks cannot. So instead you have to go directly to
the GSL block, which breaks any encapsulation we might have hoped for.

If this is the problem, then the right solution is, as you do,
to go directly to the block. So then my question is, what
would you like to see us do with gsl_block in order to make
this mapping easier?

Do you think gsl needs another abstraction in the middle,
which is closer to the VSIPL block notion? That might be
overkill, but it wouldn't be too hard.

Is the real question here ownership and the possibility
of overlaps, or is it something else?


> VSIPL uses an offset to do this. VSIPL views are more flexible
> than GSL views, so not any VSIPL view is mapable to a GSL view, but with
> knowledge of both libraries it seems to be pretty reasonable to use them
> together, at least at first glance.

GSL views may be less flexible simply because we have not
fleshed them out more. But I don't see them as fundamentally
less flexible. Do you agree, or do you think there is a
real flaw there?

Anyway, if I understand what you mean, then the right thing
to do is to make it easier to do the correct
mapping, which is blocks to blocks, with the 
two separate view abstractions remaining in
their own worlds. There may be no reason to
attempt to map the two different views to
each other in any way.


> So, by now your probably really confused.

Probably. You can judge.


Thanks.

-- 
G. Jungman

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