Re: gsl_quaternion proposition

["Robert G. Brown" <rgb at phy dot duke dot edu>]

On Fri, 12 May 2006, picca@synchrotron-soleil.fr wrote:

> Hello
>
> look at http://www.perwass.de/cbup/programs.html
> he wrote a clifford algebra library and it seems to be GPL. So no need
> to add it to gsl The work have already be done.
>
> Nevertheless as gsl_complex exist don't you think we can add a gsl_quaternion to have possibilities to do "basic" calculation with this mathematical object ?
> Peoples like me are just using it for it's isomorphisme with O(3), and I do not think that I am the only one ;).

How very cool.  I'm downloading it now and will let you know after I've
played with it a bit.  As I said, the issue is the difficulty of adding
more general structures to the GSL when specific structs are already
there.  Because there is a matrix and a vector, adding a tensor is much
harder -- it provides two incompatible ways of doing the same thing and
doesn't seamlessly integrate into existing library calls.

Because there are real and complex (and maybe quaternion), will adding
clifford (which embraces all three) be much harder?

Then there are issues with the tightness and encruftedness of the
library itself.  As Linas says, there are probably not THAT many people
who use quaternions AS quaternions, and they can be coded one of several
ways according to their needs using GSL calls and/or ordinary code as it
is.  Yet (I think that) it is certainly desirable to have a common,
clean interface for them if only because it permits common debugging and
a certain element of code portability.  However, there IS a global issue
here -- how many people have to use some particular chunk of numerical
code before it is a candidate for inclusion in the library?  How
"important" does it have to be?

If the answer is "anything anybody wants badly enough to contribute" the
library maybe ends up bloated and inadequately maintained in patches as
folks introduce code and then abandon it to the core maintainers (who
may not understand it all that well).  So far this seems to be done via
a sort of consensual dictatorship, which is as it should be --
discussion on list, but the real maintainers have the last word (and if
you don't like it, become a real maintainer and help out:-).

This has to be balanced in the long run against the near-certainty that
some early design decisions were wrong or inadequately scalable, and the
almost-certain need to add major new components that will not cleanly
interface with existing ones the way things stand.  We've already seen a
little bit of this.  The solution in general is to have a development
version where things are permitted to really break as major new
components are added, whole chunks of structs are redefined (as
backwards compatibly as possible) and then do a major version bump on
the debugged release, signalling that this release may require that you
modify your older code.  That's the kind of thing that is probably
required to shoehorn in tensors AND make matrix/vector types a
consistent subset.  This is obviously very disruptive and can only
happen a very few times over the lifetime of a major library or people
will abandon it because of the maintenance demands it makes on them.

So it pays to proceed very slowly and deliberately, no?

  rgb

> Frederic

--
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb@phy.duke.edu