Re: [pure-lang-users] case

[Eddie R. <er...@bm...>]

On Thu 28/08/08  5:25 PM , Albert Graef Dr....@t-... sent:
> Coming to think of it, it's even better if you write a wrapper function
> for each type of matrix in C, which takes a list (as a pure_expr*) as 
> argument and returns a matrix. That would execute *much* faster since 
> you only have a single function call per matrix. (You don't initialize a
> big matrix with n^2 function calls in C either, or do you? If GSL 
> doesn't provide a direct way to initialize a big matrix then that'd be a
> major performance hog.)

It has functions for initializing to zero, idenity, or all the entries the same value. However, since the data is laid out as an 
array of doubles, ints for gsl_matrix_int, (you get the picture) all I have to do is flatten a list of lists and memcpy'em in.

struct {
  unsigned int size1; //number of rows;
  unsigned int size2; //number of cols;
  unsigned int tda;   //number of entries per row
  double * data;      //here is where the data is
  ...
} gsl_matrix;

A matrix m's cell is accessed like m->data[row*size2+col].

> Yes, it is. The Q modules work that way, too. When you have a complex C
> library, almost invariably you need some additional support routines for
> accessing the data, and that stuff is best written in C. Then you have a
> little Pure module which hides away all the complexity, loads the 
> necessary C libraries and provides any high-level definitions 
> (overloading operators etc.) that you want. All the Pure programmer ever
> sees is that Pure script.

Ok. You made up my mind for me. The C wrapper is not difficult to make for Pure. You are right it is still faster to make a call 
to a call to a call than go through all the support within Pure. I noticed that even optimized gcc makes a call for a cos 
operation when it could plainly use a direct CPU fcos call.

e.r.