Bigloo and the gsl (gnu scientific library)

[chain...@hotmail.com]

Just for the unlikely case that one is working on that specific
project. I posted the following on the Bigloo mailing list. Any ideas
and hints? Post1 and Post2:

====
Hi:

I saw by chance that guile has some bindings to the "gnu
scientific library". I never used that binding, but I recognize that
they /must/ have made it by some helper tool. I cannot imagine that
they did it by hand, because the included header files are many!

As I see it, one needs the extern type definitions for harnessing the
gsl from within Bigloo; and one can then use the gsl as it is
documented in their manuals, though, it feels a bit like C, but it is
a good first step.

But I am not sure whether cigloo is capable of handling it. I am not
good at C programming, and do not exactly know what type_t actually is
(I recall having red of it somewhere ...).

The following is only a test code snippet where cigloo fails because
it does not know type_t. I tried then to hand code it, but type_t is
still unknown:

;; code snippet from the "gsl_histogram.h"

==
typedef struct
{
size_t n ;
double * range ;
double * bin ;
} gsl_histogram ;

(gsl_histogram * gsl_histogram_alloc (size_t n);

etc...
==

==
(module foo
(extern
(include "./gsl_histogram.h")
(type gsl_histogram
(struct (n::size_t "n")
(range::double* "range")
(bin::double* "bin"))
"struct gsl_histogram")
;;
(gsl_histogram_alloc::gsl_histogram* (size_t) "gsl_histogram")))
==

But let me further ask:

1. Making all that by hand is nearly impossible even if one uses
only some of the gsl libraries.

2. A lot of the header files itself rely on other foreign header
files. How to cope with that? Would a huge big header file, where all
the gsl header files rely, cure the situation? Btw: a lot of header
files have got the following:

==
...
#ifndef __GSL_RANDIST_H__
#define __GSL_RANDIST_H__
#include <gsl/gsl_rng.h>

#undef __BEGIN_DECLS
#undef __END_DECLS
#ifdef __cplusplus
# define __BEGIN_DECLS extern "C" \{
# define __END_DECLS \}
#else
# define __BEGIN_DECLS /* empty */
# define __END_DECLS /* empty */
#endif

__BEGIN_DECLS

unsigned int gsl_ran_bernoulli (const gsl_rng * r, double p);
double gsl_ran_bernoulli_pdf (const unsigned int k, double p);

etc...
==

To manage somehow to get the header files to work would really be very
good, because it would be sad that one had to use guile for using the
gsl.
====

====
I feeld a desire to add that the gsl is not solely another blas or
linpack project. It goes beyond standard lin-algebra problems. The gsl
is a bit like "Numerical Recipies". I mention that yet because I
always thought that the gsl is just another matrix and linalgebra
package.

I am just exploring it and no expert, but a binding should pay off. It
is true that in ones life one will only utilize a limited number of
all the numerical libraries and problem domains, but it is also
convenient to have the whole binding at one own shelf.

http://www.gnu.org/software/gsl/

==
The complete range of subject areas covered by the library includes,

Complex Numbers
Roots of Polynomials
Special Functions
Vectors and Matrices
Permutations
Sorting
BLAS Support
Linear Algebra
Eigensystems
Fast Fourier Transforms
Quadrature
Random Numbers
Quasi-Random Sequences
Random Distributions
Statistics
Histograms
N-Tuples
Monte Carlo Integration
Simulated Annealing
Differential Equations
Interpolation
Numerical Differentiation
Chebyshev Approximation
Series Acceleration
Discrete Hankel Transforms
Root-Finding
Minimization
Least-Squares Fitting
Physical Constants
IEEE Floating-Point
==

One may not forget that a binding to Python is surely under way or has
been realized even; I assume the latter. They are always quick.

I mean in a first step a simple "gsl-include.sch" would serve fine. It
will be a good and sound base. And people can then refine it step by
step and producing comfortable wrappers around it. That's how I did it
with DISLIN.

====

Fensterbrett

[tal...@noshpam.lbl.government]

size_t looks to me like a user-defined type (via typedef). Are you
sure there isn't another header file that this header file includes?

BTW, you may want to look at LUSH ( with the misnomer "Lisp Universal
SHell" ), which is a Lisp with many bindings to mathematical /
scientific libraries.

I'm interested in similar things, so keep me posted. :-)

~Tomer

chain...@hotmail.com writes:

--
()

[Hartmann Schaffer]

In article <f7afbb21.04032...@posting.google.com>,

chain...@hotmail.com writes:
> But I am not sure whether cigloo is capable of handling it. I am not
> good at C programming, and do not exactly know what type_t actually is
> (I recall having red of it somewhere ...).
>
> The following is only a test code snippet where cigloo fails because
> it does not know type_t. I tried then to hand code it, but type_t is
> still unknown:

from the code snippet you supplied i suspect you meant size_t.

size_t is a type that defines an integral type that can be used to
specify things like array extents, subscripts, etc. it has to be
defined in one of the standard header files that are prescribed by the
ANSI standard, and you would have to include that file for the system
you are compiling for before cigloo encounters the typedef for
gsl_histogram.

Sorry, but I don't have the standard at hand, but i would first ;look
into types.h. Most likely you will find a description of size_t in
the documentation. the documentation for the library that comes with
gcc tends to mentin the include file that is needed to include the
definition

hs

--

Patriotism is the last refuge of the scoundrel
Samuel Johnson

Patriotism is your conviction that this country is superior to all
others because you were born in it
George Bernard Shaw