Re: Guile numerical work and uniform arrays

[Dirk Herrmann <dirk@ida.ing.tu-bs.de>]

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

That's true, but one of the reasons is, that the current system of builtin
types is a mess. And this is due to the fact that there are already lots
of non-standard types implemented in the core (like uniform arrays).

> 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 was surprised that there is even a special read syntax for uniform
arrays of different types. I don't do a lot of scientify computing, but
what would be the disadvantage of providing a smob for each type of
uniform array in a library? Instead of special read syntax, you would have
to provide functions make-uniform-int-vector and the like. By adding
access and conversion functions uniform-int-vector-ref and
uniform-int-vector->vector (or similar) you can have easy access on the
scheme level. Since the smob is implemented as a C array, you can also
easily pass the vector to the C functions mentioned above.

In my opinion, guile's type system should be vastly simplified by moving
most non-standard built-in types into smobs (and maybe even some standard
ones: bignums currently use up two smobs, one for positive integers and
another one for negative ones, oops). Obviously, this should go together
with extending the smob space, but I think both steps depend on each
other.

I am not even sure if, instead of a performance loss, this would speed up
things in the common case: Currently you get struct types, bignums,
uniform vectors of all flavours, independent of whether your application
needs them or not. Even if you do scientific computing, you will probably
not need a uniform vector of characters or shorts. Nevertheless, the code
is in there and in some places guile checks an object against all known
built-in types.

Best regards, 
Dirk Herrmann

--
This message is best viewed with ISO 8859/1 (latin-1) character encoding.
              Microsoft .. what do you want to boot today?