GSL blocks, arrays, matrices

Hello all,

The GNU Scientfic Library (GSL) has some nice capabilities, and it is
time for me to wrap it in Dolphin to give it a try.  Its memory
allocation works by blocks (structs that point to a buffer and describe
the length and element size), and then vectors and matrices that are
other structs that point to a block and then have addition row/column
descriptions as appropriate.

GSL has a fairly elaborate set of alloc/free style functions for
creating blocks and then vectors/matrices, or creating a vector or
matrix with the block seemlessly created and owned by the created
entity.  At least, that is my limited understanding from skimming the
manual.

My sense is that I would be better off by doing the memory management in
Dolphin.  The nested life times of the various blobs of memory at least
seem intuitive enough, and doing it in Dolphin would avoid finalization,
shutdown/startup handling, etc., that goes along with external memory.
If GSL "knows" about the blocks it creates and won't work with arbitrary
blocks, I think I would consider that a scary code smell, unless there
turns out to be a very good reason for it.

Comments?

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

Didier H. Besset "Object-oriented implementation of numerical methods"
have some part of the linear algebra topic. It has also a Dolphin
implementation in SourceForge. Well, it does not have FFT...

Otherwise it seems to be a wise decision.

Best regards,
Janos

Bill,

> The GNU Scientfic Library (GSL) has some nice capabilities, and it is
> time for me to wrap it in Dolphin to give it a try.

Good luck to you.  In my experience (limited), trying to use GNU library
software on Windows is likely to be a nightmare...

Just for starters, I don't know of a way for Dolphin to load a Cygwin .a
library...

Or maybe you are considering the commercially supported version from
    http://www.network-theory.com/gsl/cdrom/
 which seems to include VC++ support ?


As far as I can see from a quick scan, there is no published interface for
replacing the library's allocators.  Without that you'd be delving into places
you probably don't want to go.  In particular if the library hasn't been
designed for pluggable allocators (and it should have been, but appears not to
have been) then it may be dangerous.  If I /had/ to replace its allocators, I
would recompile the library with malloc(), calloc(), and free() #defined to
point to a function pointers which could be replaced by Dolphin
ExternalCallbacks -- but I wouldn't do that unless I /had/ to...

It seems to me that the advantage of using a Dolphin-supplied allocator is
pretty small compared with the risk of driving the library in a way that it is
not designed for.

Note also that you'd have to make extra provision for protecting
Dolphin-allocated blocks from its GC in case the only reference to the block
was via binary addresses stored in some other block, or in the GSL library's
own data.

Slightly off-topic; tangentially relevant at best.  I'm dubious about using GPL
software in a Dolphin application.   There doesn't seem to be much to gain by
using a GPLed library to create an application which you can't distribute (and,
IMO, "distribution" includes installing it on users' machines in your own
organisation -- but that is only an opinion, mind).  For example, over the last
couple of days I've put together a rather nice little IA-32
assembler/disassembler based on wrapping the "Disasm" library associated with
OllyDbg[*].  It seems to work well, and I'd like to distribute it and/or
applications built with it -- but that's impossible because I /won't/ GPL my
own software and I /can't/ GPL OA's software....

    -- chris

[*] http://www.ollydbg.de/

Chris,

>>The GNU Scientfic Library (GSL) has some nice capabilities, and it is
>>time for me to wrap it in Dolphin to give it a try.
>
>
> Good luck to you.  In my experience (limited), trying to use GNU library
> software on Windows is likely to be a nightmare...
>
> Just for starters, I don't know of a way for Dolphin to load a Cygwin .a
> library...

Does

   http://gnuwin32.sourceforge.net/packages/gsl.htm

change things?  It ships w/ DLLs.  Please feel fre to be blunt.



> Or maybe you are considering the commercially supported version from
>     http://www.network-theory.com/gsl/cdrom/
>  which seems to include VC++ support ?

Hadn't seen it.  I will take a look, if only to see what I can learn
about what they did and how.


I assumed their allocators are nothing more than wrappers around
malloc() and friends w/ some initialization.  I could be wrong though,
so it is worth a look at the source.


> Note also that you'd have to make extra provision for protecting
> Dolphin-allocated blocks from its GC in case the only reference to the block
> was via binary addresses stored in some other block, or in the GSL library's
> own data.

Specifically with respect to contained pointers in GSL structs, I
_think_ one could simply, for example, allocate a matrix and hold the
underlying block as part of it, making the life cycles idiot proof -
part of why I want to pass on their allocators.  I share at least some
of your reservations about the design.  IIRC, and if I understood
properly, there was an apparently needless/implied size parameter in the
FFT routines that first gave me pause.


Good point, though I doubt it has much practical impact, as the
alternative so far is Numerical Recipes, which is also restrictive.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

[me:]
Yes, definitely.


> > Or maybe you are considering the commercially supported version from
> >     http://www.network-theory.com/gsl/cdrom/
> >  which seems to include VC++ support ?
>
> Hadn't seen it.  I will take a look, if only to see what I can learn
> about what they did and how.

I suspect that the GnuWin32 port will provide pretty much the same thing...


> I assumed their allocators are nothing more than wrappers around
> malloc() and friends w/ some initialization.  I could be wrong though,
> so it is worth a look at the source.

I have looked at bits of it here and there, and I've changed my mind.  They do
seem to be mere convenience functions, with no implication that you /have/ to
use them to create the relevant structures.  Also, there don't seem to be
"hidden" references from blocks to other blocks -- matrixes are not vectors of
vectors for instance.  So it looks to me as if, in this case, re-creating the
allocation/deallocation methods in Dolphin would be quite a lot simpler than
wrapping and using the supplied allocators.

I'd still be wary about the library using free() or realloc() on a pointer
which it hadn't allocated, but that's just natural caution -- a reason to be
alert for bugs, not a reason to adopt a less convenient approach without even
trying the simple one.

    -- chris