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 writes:
 > >>>>> "Klaus" == Klaus Schilling <Klaus.Schilling@home.ivm.de> writes:
 > 
 >     Klaus> Mark Galassi writes:
 >     >>  Dear numerical scheme enthusiasts,
 >     >> 
 >     >> Jim Blandy has asked me if I could get some people together for
 >     >> a private discussion of uniform arrays and other Guile features
 >     >> needed to support scientific computing.
 >     >> 
 >     >> The motivation is the following: uniform arrays (kind of like
 >     >> vectors, but the elements are all the same size, thus allowing
 >     >> storage similar to a C array) make Scheme a convincing language
 >     >> for numerical work, but the current design and API could do
 >     >> with some improvements.
 > 
 >     Klaus> What is the advantage of using uniform arrays over
 >     Klaus> application-specific smobs as in Chris Lee's example for
 >     Klaus> g-wrap (from the Meschach lib)?  The gsl already contains a
 >     Klaus> few matrix utilities which might be wrapped as well.
 >     Klaus> Chrlib seems to work along these lines, based on BLAS and
 >     Klaus> LAPACK.
 > 
 > 
 > 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.

Yeah, that's a problem. Hasn't someone already posted a prospective solution
for the dilemma of lack of smob-type slots? 

A temporary solution might be
union smob types, which add an additional indirection:

struct many_types
{
ulong type_tag;
union types
{
type1 *t1;
type2 *t2;
type3 *t3;
/* and so on*/
}
}

then typedef many_types as a new struct type and define a smobtype whose
cdr is a pointer to a many_types, and the smobfuns would contain switch-case
-constructs for type_tag.

this is of course non-dynamic, adding new types would require rewriting 
and recompiling many_types and all its associated smobfuns by hand.

Most likely it is pretty bad performance either.

     Klaus Schilling