This is the mail archive of the guile@cygnus.com mailing list for the guile project.


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

Re: Guile numerical work and uniform arrays


Clark McGrew wrote:
> 
> >>>>> "Klaus" == Klaus Schilling <Klaus.Schilling@home.ivm.de> writes:

[snip]

> 
> The reason I find uniform arrays useful is that "uniform array" is a
> really common data type in my work.  I'd like to see all of the basic
> machine types available as uniform arrays, AND a way to request a
> particular representation from scheme.  As long as the layout of a uniform
> array is equivalent to a C array, and the basic type can be
> gaurranteed, the address of the data can be passed directly to a
> routine that expects a C array.

I need to make use of such arrays, and I have put together a set of
routines.   These have been substantially updated since my last
announcement to the list.  See:
http://www.niss.org/~stark/software/gmat.zip

(Yes,) I have had discussions with Chris Lee.  My aim has been to create
the smallest yet most flexible set of tools.  (I have also had to work
around some misfeatures in Guile which will get fixed.)  Chris' system
is a lot more powerful.

In our discussions, Chris and I realized that transferring data around
from one package to another was a lot more complicated than first
appears.  For example, who does the allocation?  What happens when one
user of the data deallocates whilst another still thinks it is valid?  I
have used images in Tk, and something similiar to the notification
system incorporated in that would be required.  A basic scheme might be
as follows: when a package makes use of an array, it should register
that use.  When an array is modified, all users would be notified,
probably with some indication of which part of the array is affected.

In summary, I think that this is an important issue.  Also, whilst GWRAP
might be the route of choice for many, a lean and effective API within
Guile for handling these kinds of data objects would be valuable.

Alex.