Re: gsl Development Query

[Randall Judd <judd at nosc dot mil>]

At 06:45 PM 09/04/2000 +0100, Brian Gough wrote:
>Randall Judd writes:
> > In VSIPL every view contains a pointer to the block. 
>
>I think we can accomodate this in GSL by not setting the block field
>to NULL for views, and having a separate field in the struct to
>indicate ownership of the memory instead.  Then one would always be
>able to determine the underlying block for any view.
>
>This seems straightforward to support, so I will do that -- it only
>needs a change in the struct defn and a few associated routines.
>
This would be good. I would then have enough information from the view to
create a matching VSIPL view and to check and see if the gsl block was
owned by the gsl view or not.

In VSIPL we leave it up to the user to keep track of what belongs with what
block and it is the users responsibility not to destroy the block before
everything is done using it. We have destroy (what your spec calls free)
functions for both views and blocks and an all destroy if we want to
destroy both view and block attached to view. For instance 
vsip_blockdestroy_f(vsip_block_f* vsip_vdestroy_f(vsip_vview_f*)) 
or 
vsip_valldestroy_f(vsip_vview_f*). 

For a developement mode VSIPL library we use a block attribute which
contains a number indicating valid when the block is made. When the block
is destroyed we set the number to invalid. This allows an implementation
(the user could not do this) to check and see if the block is valid or not.
Of course you don't check for invalid. The implementation needs to check
this in VSIPL because of the way we designed the library.

In section 6.1 of the GSL manual I downloaded I notice typdefs for complex
blocks, but I don't see anywhere where they are defined. Are the in the
manual? How is the stride handled? VSIPL strides are in terms of block
elements so the stride for real and the stride for complex are handled the
same. Historically many vector libraries do strides in terms of real
elements, even for complex. How does GSL handle this? Are there any
functions yet that need these comples blocks?

I run across an error from time to time in the manual. Is their a place to
send these too? For instance the example on page 246 has in the first for
loop,
REAL(z,i) = 0.0; which should be I think REAL(data,i)=0.0;

I spent (and am spending) a fair amount of time editing VSIPL specs and I
know how much trouble it is to get rid of errors. I just don't know if you
want me sending them to this mailing list.

               Randy Judd