commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tanguy Yannick" <Yannick.Tan...@cnes.fr>
Subject RE: [math] Adding a new class to handle Matrix with 3 columns/rows
Date Thu, 28 Jul 2011 16:40:05 GMT
-----Message d'origine-----
De : Phil Steitz [mailto:phil.steitz@gmail.com] 
Envoyé : mercredi 27 juillet 2011 18:50
À : Commons Developers List
Objet : Re: [math] Adding a new class to handle Matrix with 3 columns/rows

>On 7/27/11 12:01 AM, Luc Maisonobe wrote:
>> Le 26/07/2011 17:59, Tanguy Yannick a écrit :
>>> Hello,
>>>
>>> In project SIRIUS (CNES), we have some need for a Matrix33 (3 
>>> columns, 3
>>> rows) object. It is very common to use this kind of matrix to apply 
>>> rotation to a position vector (vector3D).
>>>
>>> The incompatibility between the Vector3D of geometry package and the 
>>> matrix/vectors of the linear package is a lack that we propose to 
>>> fill by creating a "Matrix33" in the geometry.threed package.
>>
>> Looks finie to me.
>>
>>>
>>> This new matrix will only propose basic methods, optimized for this 
>>> size of matrix : add, substract, product (Vector3D or Matrix33), 
>>> transpose, determinant, isSymmetric ..
>>
>> Do you intend to provide solvers too ? For such small size matrices, 
>> with an explicit dimension, it could even be done using inlined Cramer 
>> method.
>>
>>
>> We will also propose some new constructors to build gaps between this 
>> new matrix and the matrix of linear package.
>>
>> Yes, having a way to change from one view to the other is a clear 
>> need.
>>
>>>
>>> Thanks for your advice about this feature.
>>
>> As per all contributions you may propose, be aware of the Apache 
>> Software Foundation motto you will see at the beginning of the 
>> foundation home page: "We consider ourselves not simply a group of 
>> projects sharing a server, but rather a community of developers and 
>> users."
>>
>> We are happy to get contributions, but only as long as they come with 
>> some involvement and willingness to maintain them. Of course, very 
>> small contributions can be dealt with by the existing community, but 
>> we simply don't have the resources to maintain large contributions we 
>> didn't wrote and which are dumped at us.
>
>To expand and clarify a little this last point - we are much more interested in volunteers
than code.  Code that comes with volunteers actively engaged in developing and maintaining
it gets attention faster because it helps us grow the community.  Volunteers who stick around,
play nice in the community and submit consistently good patches get voted in as committers,
increasing our capacity to accept more patches, develop more features, fix more bugs and cut
more releases.  Significant code contributions without volunteers to support them move things
in the opposite direction - exacerbating the resourcing problem Luc mentions.

I understand what you say. Our project is rather new and the development has just begun. Furthermore,
it's really the first time we use open-source building blocks for our spaceflight tools.
We are several people involved within the conception & development stages and I think
that my other colleagues will also be interested in joining the list to discuss about evolutions,
bugs, etc.
As the Commons Math is the "foundation" of our tools, we will have to be implied in the maintenance
of this library for our users, and therefore for other people in the community. 
I hope it will help the Commons Math project !

Best regards,

Yannick

>Thanks in advance for your help!

>Phil
>
>> best regards,
>> Luc
>>
>>>
>>> Yannick TANGUY
>>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message