Re: Guile numerical work and uniform arrays

[Jim Blandy <jimb@red-bean.com>]

These are questions of exactly the sort I hope the Guile numeric group
can come up with authoritative answers for.  If everyone using arrays
says, "Yes, that's what we want", then I can feel much more
comfortable supporting it.


> There's a minor inconvenience with smobs.  There is a rather limited
> number available (256?).  If really big libraries are wrapped
> all of them could be eaten up rather quickly.

That can/will be fixed.

> 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. 

Okay, so here's the $64k question:

Do you want all of "the basic machine types" available for use in
uniform arrays?

Or do you want all of "the types corresponding to the C and FORTRAN
types" available?

That is, what do you want to specify in your Guile code --- 64-bit
IEEE float, or "whatever a C `double' is on this machine"?

Is the purpose to mesh with libraries written in C or FORTRAN, or to
have exact control over the bytes?


> I would also find it very useful if there were a way to get guile to
> treat a region of memory as a uniform array (and not try to GC the
> memory block).  This would let me attach to large chunks of memory
> allocated by other packages.  

Should Guile call a hook associated with the array to free its space?