Re: gsl_quaternion proposition

[picca at synchrotron-soleil dot fr]

> 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?

I do not know about this. Maybe looking at the sources of the club
librarie may help to understand how to design struct for clifford
algebra.

> 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?

So we need some feed back of potential users. let's send a message to
gsl users and ask if peoples would be interested in a quaternion type ?
and what they plan to do with them if they were included in gsl.

More generaly can't we ask users to vote for things to add in gsl.
Create a list of priorities etc...

> 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:-).

I agree with this that's why I propose to maintain the quaternion part
and sent my work to let you decide if the code is clean enought to be
included in gsl. It is very similar to the gsl_complex type so I must
not be so complicate to maintain. Or maibe I miss some points :).

> 
> 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?

Yes so it is up to you to decide if quaternions have their room in gsl.

frederic.