GSL collaboration 
Author Message
 GSL collaboration

A few thoughts about the GSL idea:

Poplog already has the vec_mat package which does some useful numerical
stuff. It was produced by Harry Barrow and Jim Stone some years ago. I
think it was funded by a research council and so ought to be freely
available, but it doesn't seem to be on the Birmingham web site, unless
I've missed it. For anyone who is looking for vector and matrix
operations now, it could be useful, though its scope is limited compared
to GSL, and I have found the odd bug. I seem to remember that they based
it on "Numerical Recipes" but I'm not certain. (Aaron: it's in the local
tree at Sussex.)

GSL looks like it has very good coverage, but I don't know anything
about the quality of the routines. I always think of the gold standard
as NAg (see http://www.*-*-*.com/ ) which pays huge attention to detailed
and subtle but vital numerical issues - stability and error propagation
and all that. If GSL can compete in that area, then it could be
extremely useful. Anyone know of a review or anything that looks at
their testing regime?

I started writing an interface for the NAg fortran library years ago but
never had time to really follow it up. Drawbacks were that you have to
buy NAg, Fortran compilers became seen as rather esoteric things that
also needed special licences, and the NAg C library, when it became
available, didn't have the same coverage as the Fortran library. I think
this work did have some useful spin-offs in improving the interfaces for
external linking, which were used for some of the X-windows interface.

Anyway ...

If GSL is good, then I agree with Aaron about what would be useful, viz:

Quote:
> I was thinking more of providing convenient pre-packaged interfaces
> with some limited documentation, which would point to the full GSL
> documentation.

and

Quote:
> ... (A pop11 program reads the
> GSL documentation, and then genrates all the interface files ?????)

[Maybe it would be sufficient for it to read the header files?]

Ideally an installer ought to be able to download and compile GSL and
then generate the interface just by specifying a path and running a
procedure. After that, a user should be able to say "uses gsl" and then
be able to able to run gsl routines via Pop-11 routines, without ever
looking at HELP/REF EXTERNAL.

However, there are some hard bits. One is dealing with the GSL macros.
Another is deciding whether Pop-11 arrays can be passed to the gsl
procedures, or whether the user has to do some explicit translation.
There are, I suspect, quite a few similar major representation issues.

I'm not volunteering to do anything about it just yet, but I am
interested in the project.

David



Sun, 16 Nov 2003 20:57:34 GMT  
 GSL collaboration

Quote:

> >Presumably 'senior member(s)' have judged that the cost/benefit says
> >do-it.

> Do what?

A pre-feasibility study; which has already started.

Quote:

> What I was proposing can be compared with two things that already exist
> in Pop-11:

> (a) The X window system provides a large collection of utilities for
> managing graphical displays along with mouse and keyboard events,
> written in C. The poplog developers wrote lots of C code, and Pop-11
> code to invoke the C code, along with a lot of documentation....
> ... snip ...

> (b) David Young at Sussex University produced a library with a
> collection of utilities and documentation for using or learning about AI
> vision techniques.

> His popvision library, browsable here
>     http://www.cs.bham.ac.uk/research/poplog/popvision/
> or retrievable here:
>     http://www.cs.bham.ac.uk/research/poplog/popvision.tar.gz

> includes a number of image manipulation programs written in C.

> To make them accessible for users he has Pop-11 wrappers. The
> popvision/lib/ subdirectory has a bunch of files some defining C
> programs and some defining Pop-11 procedures to invoke the C programs.
> .... snip ...

> --------------
> This file documents the GNU Scientific Library, a collection of
>    numerical routines for scientific computing.

>    As of 21 May 2001 the library is in developers release only and is not
>    recommended for general use.
>      * Preliminaries
>      * Using the library
>           + ANSI C Compliance
>           + Compiling and Linking
>           + Shared Libraries
>           + Automake macros
>           + Inline functions
>           + Long double
>           + Portability functions

 .... snip rest of MASSIVE structured index ...

It seems to be an exercise in interfacing poplog to Unix Code (libraries) ?
How much can be 'taken over' from the 2 projects mentioned above ?
Am I being simplistic in hoping that a unified method can/should exist to
interface poplog to ANY Unix Code ?

Just testing the GSL facilities would be a massive task.
Perhaps 'automation' to do such testing already exists ?

-- Chris Glur.



Fri, 21 Nov 2003 03:10:23 GMT  
 GSL collaboration
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Quote:
>A few thoughts about the GSL idea:

[Details about other libraries, e.g. NAG, omitted]

Quote:

>Anyway ...

>If GSL is good, then I agree with Aaron about what would be useful, viz:

>> I was thinking more of providing convenient pre-packaged interfaces
>> with some limited documentation, which would point to the full GSL
>> documentation.

>and

>> ... (A pop11 program reads the
>> GSL documentation, and then genrates all the interface files ?????)

>[Maybe it would be sufficient for it to read the header files?]

I agree. For GSL, or any package to work as a library, all of the public
interface should be declared in the header files. They would be easier
to work with than the documentation.

I believe Aaron wants a slim volume of interface documentation for
Poplog users. A very formulaic interface reference document can be
generated from the same header files as the interface itself, possible
segmented according to the directory or file segmentation of the
original source. We may be able to correlate this segmentation with
chapters of the original documentation, and if it is sufficiently well-
structured, we may be able to pull descriptive text to accompany
translated-header-based function descriptions.

It would be an interesting exercise to define coding and documentation
standards that support this type of transformation effort. Perhaps the
Gnu community has already done this?

Quote:
>Ideally an installer ought to be able to download and compile GSL and
>then generate the interface just by specifying a path and running a
>procedure. After that, a user should be able to say "uses gsl" and then
>be able to able to run gsl routines via Pop-11 routines, without ever
>looking at HELP/REF EXTERNAL.

I think that this route is essential. If we include GSL with Poplog,
then I believe Poplog's license will have to be a GPL.

Quote:
>However, there are some hard bits. One is dealing with the GSL macros.
>Another is deciding whether Pop-11 arrays can be passed to the gsl
>procedures, or whether the user has to do some explicit translation.
>There are, I suspect, quite a few similar major representation issues.

In general, when generating a Pop-11 interface to an arbitrary library,
then there will be substantial representation problems to be dealt with.
However, I have been slowly analysing the code, and so far, I think GSL
provides few of these.

Starting with the C macros, these divide into public constants, private
constants and genuine macros. I hope that none of the macros constitute
part of a public interface - if they do, then GSL would only be usable
when included as source code in a project. I think it is more likely,
given the stated intentions of the authors that these macros are only
private and can be ignored by Poplog. (Note that I haven't yet got a
successful build of the libraries, as my download appears to contain a
large number of configuration faults).

Of the remaining constants, I initially thought we would have to filter
the headers to locate "#define" statements, and further filter with a
simple rule that tests if the macro value is numeric. In general, we can
extend this to provide a mechanism for importing constants from any
package into a "#define" filter over the file tree, piped through a rule
applier that selects relevant macros. E.g. we could write Poplog pattern
matching rules to ignore anything that parsed as C/C++ code.

Looking more closely at the GSL source, there is a gsl/const directory
with several header files. This may be the only place to declare
constants that are part of the public interface. Whether this is so, or
not, we can generalise our file filter for the constants translator to
include rules for only looking at certain files.

My process generalisation for this part of an interface generator then
becomes:

[Directory] -> (Tree Lister)
            -> (Directory Filter)       <- [Directory List]
            -> (Filename Filter)        <- [Filename List]
            -> (Hash Define Filter)
            -> (Constant Rule Applier)  <- [Statement Rules]

This uses an optional directory list, a filename list and a statement
rule-set. The statement rule set might include filter rules to select or
discard statements under consideration, and transformation rules to
generate the target statements that "translate" the original. We will
see similar components in the remaining components needed to process
public functions, type definitions and any global variables, so it may
make sense to generalise these data sets and label them in sections
relevant to each class of component we want to process.

I'll post suggestions regarding the handling of structures, function
prototypes, global objects and externals (file references, shared
memory, semaphores, queues, environment variables, etc.), where they are
relevant, if no-one else covers this before I've completed some further
analysis.

Quote:
>I'm not volunteering to do anything about it just yet, but I am
>interested in the project.

Ideas and m{*filter*}support are appreciated.

Quote:
>David

Regards,
- --

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1

iQA/AwUBOxyXH/Hj+enJbeYqEQJIqQCfV8N1y+TOdX9yiXrBGqSuZ0aWKVIAn0BD
0Y5Z3zueDZOSLor+JQSGQzO4
=fzHK
-----END PGP SIGNATURE-----



Sun, 23 Nov 2003 00:21:15 GMT  
 GSL collaboration
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris,



Quote:

>> >Presumably 'senior member(s)' have judged that the cost/benefit says
>> >do-it.


>> Do what?
>A pre-feasibility study; which has already started.


>> What I was proposing can be compared with two things that already exist
>> in Pop-11:

[X-Windows and Popvision details clipped]

Quote:
> .... snip rest of MASSIVE structured index ...

>It seems to be an exercise in interfacing poplog to Unix Code (libraries) ?
>How much can be 'taken over' from the 2 projects mentioned above ?
>Am I being simplistic in hoping that a unified method can/should exist to
>interface poplog to ANY Unix Code ?

In an ideal world, everything we wanted could and should exist. In mine,
nothing is ever simple, (except, perhaps, sometimes, me).

A well defined C library should have a clearly defined public interface.
This would define data types, constants, public functions, etc.

To map this to another system, we have to make the public functions
callable, the constants accessible and choose an appropriate
representation for the data types. This is a simplification.

Even with well-defined C, we cannot tell, without parsing the body of
procedures, if an argument is passed by reference for write-only usage,
i.e. it is an output argument.

In the Poplog case, we cannot therefore, readily translate from a C-
style:

  Atype foo(in1, in2, in-out3, out4);

to a Poplog style:

  foo(in1, in2, in-out3) => out4 => varOfAtype

Even if we could do this easily, we might be inclined to argue over what
the correct order for the outputs should be. We might, however, decide
this didn't matter and preserve the style of the original.

With data types, we have to choose an appropriate representation, and
then we have to plant translation code to support our chosen mapping.

E.g. Do we map the argv in:

int main(int argc, char *argv[])

to a list, a vector, a native C type made available to Pop-11 via some
other mechanism, or some other choice. Whichever choice we make, we are
trading off the convenience of the interface developer for the
convenience of the interface user.

A system such as X-Windows defines dozens of data types - cursors,
colours, pixmaps, windows, etc. GSL, fortunately, uses mostly numbers
and a few structures, so the task should be easier.

Quote:
>Just testing the GSL facilities would be a massive task.
>Perhaps 'automation' to do such testing already exists ?

GSL ships with a test suite. An interface generator that mapped GSL to
Poplog should be able to handle mapping the test suite without too much
difficulty. I think we would leave as an exercise to the reader to
synchronise GSL testing with Poplog+GSL testing, although, we may decide
this has to be done to prove that the mapping logic in our interface
functions is working as it should.

Quote:
>-- Chris Glur.

Regards,
- --

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1

iQA/AwUBOxzWrvHj+enJbeYqEQL87wCg9jWrhX/2RMtBjE3IW71B4+veyZkAnjvH
SvCNVIcE5iPaXUGPkUlcC2hm
=ITXB
-----END PGP SIGNATURE-----



Sun, 23 Nov 2003 04:53:28 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. GSL collaboration and (and GSL Manual contents)

2. GSL collaboration and formal methods.

3. GSL collaboration

4. filenames, argument list separators + gsl extension

5. Other gsl interfacing projects

6. GSL interface: another Pop-11 development task?

7. GSL and Lapack

8. ANN: ruby-gsl 0.1.6

9. ruby-gsl 0.1

10. ada bindings for gsl (GNU Scientific Library)

11. gfoftran and GSL subroutines

12. Fortran interface for GSL (alpha)

 

 
Powered by phpBB® Forum Software