Re: How to fix the GSL API

["E. Robert Tisdale" <edwin at netwood dot net>]

Eleftherios Gkioulekas wrote:

> See The Mathutil Library
>
>     http://www.amath.washington.edu/~lf/mu.dvi
>
> I quit working on this bc my hands got RSI.
> Now I do pure hard theory instead.
> Lemme know what you think...

I read your documentation.

  SVMT      VSIPL     GSL      Mathutil
-------------------------------------------
subvector vsip_vview vector  mu_type_array
submatrix vsip_mview matrix  mu_type_matrix
subtensor vsip_tview ------  mu_type_cube

Your Mathutil classes are equivalent to GSL

    http://sources.redhat.com/gsl/

VSIPL

    http://www.vsipl.org/

and SVMT

    http://www.netwood.net/~edwin/svmt/

classes.  Your Mathutil mu_membuf class
is analogous to GSL gsl_block, VSIPL vsip_block
and SVMT Handle classes.
Mathutil is NOT really a vector, matrix or tensor class library
because there are virtually no functions on any of these types.
Application programmers are obliged to implement
vector, matrix and tensor functions themselves
with loops over subscripted variables.
A vector, matrix and tensor library should try to eliminate loops
first because they offer too many opportunities
to make programming errors that are difficult to detect and debug
and second because they virtually preclude parallelization.

The vector, matrix or tensor view owns the data array
which was allocated for it when it was created.
Normally, all subvector, submatrix and subtensor views
reference a data array created for an existing
vector, matrix or tensor view and are destroyed
before the existing vector, matrix or tensor view is destroyed.
It is almost certainly an error if the vector, matrix or tensor view
which owns the data array allocated for it is destroyed
before all of the subvector, submatrix and subtensor views
created from it are destoyed.
Reference counting can be used to warn application programmers
when a data array is deallocated before all of the views
which reference it have been destroyed.
Whether or not the data array should be permitted to persist
until all of the views that reference it have been destroyed
is an implementation detail
which should be left up to the class library developer.
Objects that do reference counting cannot be shared
by more than one thread in a multithreaded program
unless the reference counter is protected by mutual exclusion
because any thread that attempts to create a subvector,
submatrix or subtensor view will modify the reference counter.