You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Tanguy Yannick <Ya...@cnes.fr> on 2011/07/26 17:59:43 UTC
[math] Adding a new class to handle Matrix with 3 columns/rows
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.
This new matrix will only propose basic methods, optimized for this size
of matrix : add, substract, product (Vector3D or Matrix33), transpose,
determinant, isSymmetric ..
We will also propose some new constructors to build gaps between this
new matrix and the matrix of linear package.
Thanks for your advice about this feature.
Yannick TANGUY
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [math] Adding a new class to handle Matrix with 3 columns/rows
Posted by Tanguy Yannick <Ya...@cnes.fr>.
>
>> For very big matrix (ie : beyond 500 or 1000 rows/columns), the
>> computation is faster if you transpose the second matrix and then
>> multiply. The two inner loops are inversed and it allows a
significant
>> gain for very big matrix (about 40% compared to Commons Math for
>> 1000x1000 matrix, and 50% compared to the classical triple loop). I
>> guess that it's faster for the JVM to access the matrix coefficients
>> in the computer's memory.
>
>For large matrices, did you compare with BlockRealMatrix ? It was
specially designed to improve caching. This is the >>reason why when you
build a matrix using the various factory methods
MatrixUtils.createRealMatrix (or createFieldMatrix), there is a test
about the dimension and either an Array2DRowRealMatrix or a
BlockRealMatrix is created. The current threshold has been set to 4096
elements, but this was an almost arbitrary choice.
>best regards,
>Luc
You are right, BlockRealMatrix is even more efficient : 4x faster than
our implementation, and 6x faster than the Array2DRowRealMatrix for big
Matrix...
Yannick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Adding a new class to handle Matrix with 3 columns/rows
Posted by lu...@free.fr.
----- Mail original -----
>
>
> -----Message d'origine-----
> De : Phil Steitz [mailto:phil.steitz@gmail.com]
> Envoyé : jeudi 28 juillet 2011 18:32
> À : Commons Developers List
> Objet : Re: [math] Adding a new class to handle Matrix with 3
> columns/rows
>
>
> >> The key point here is that the matrix from linear package are not
> >> compatible with Vector3D.
> >> -> This is the main point we wanted to solve by creating a new
> >> matrix
> >> class.
> >> So we have imagined three solutions :
> >> a) inherit the RealMatrix, but we need to add a multiply(Vector3D
> >> v)
> >> method and some other methods
> >> b) create an adapter class which contains an Array2DRealMatrix :
> >> this
> >> may be heavy because we need to implement other methods
> >> c) create a rather small class with only a few methods that answer
> >> our
> >> needs (multiplication with Vector3D, transposition, ...). This
> >> class
> >> should also implement a specific constructor and a specific getter
> >> to
> >> fill the gap with the RealMatrix.
> >>
> >> The other advantage of the c) solution is that it allows to
> >> implement
> >> faster operations.
>
> >How, exactly, do you expect to be able to improve speed in a way
> >that would not apply to Array2DRowRealMatrix? If there >are faster
> >implementations of the direct array-based operations we should make
> >them available to both classes. Having an extra set of matrix ops
> >to maintain just for 3x3 matrices does not sound like a happy
> >prospect to me.
> >
> >Phil
>
> Sorry I made a mistake about the performance of matrix multiplication
> (see below). Nethertheless, the problem of performance is secondary,
> since the first reason why we want to add a new Matrix3D class is
> that the generic implementation is not compliant with Vector3D from
> geometry.euclidian.threed package.
>
> Here are some observations we made about performance while operating
> small or big matrix.
>
> We made several tests because in our softwares, we use either small
> matrix (3x3 or 6x6) to handle position & velocity of a spacecraft or
> very big matrix (hundreds or thousands of lines & columns) in some
> orbit restitution tools.
> For 3x3 matrix, it's possible to remove the triple loop, by writing
> directly the 9 sums of products from A & B matrix coefficients. Of
> course, it's not possible for generic matrix. In our old software in
> Fortran, it could save about 17% compared to the generic "matmul"
> intrinsic fonction. We made some benchmark in Java and obtained a
> gain of about 25%. But the Commons Math implementation is still
> faster ! And Commons Math is twice as fast as the triple loop
> implementation.
> -> So for small matrix, there's no need to re-code matrix operations
>
> For very big matrix (ie : beyond 500 or 1000 rows/columns), the
> computation is faster if you transpose the second matrix and then
> multiply. The two inner loops are inversed and it allows a
> significant gain for very big matrix (about 40% compared to Commons
> Math for 1000x1000 matrix, and 50% compared to the classical triple
> loop). I guess that it's faster for the JVM to access the matrix
> coefficients in the computer's memory.
For large matrices, did you compare with BlockRealMatrix ? It was specially
designed to improve caching. This is the reason why when you build a matrix
using the various factory methods MatrixUtils.createRealMatrix (or createFieldMatrix),
there is a test about the dimension and either an Array2DRowRealMatrix or a
BlockRealMatrix is created. The current threshold has been set to 4096 elements,
but this was an almost arbitrary choice.
best regards,
Luc
>
> Best regards
>
> Yannick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [math] Adding a new class to handle Matrix with 3 columns/rows
Posted by Tanguy Yannick <Ya...@cnes.fr>.
-----Message d'origine-----
De : Phil Steitz [mailto:phil.steitz@gmail.com]
Envoyé : jeudi 28 juillet 2011 18:32
À : Commons Developers List
Objet : Re: [math] Adding a new class to handle Matrix with 3 columns/rows
>> The key point here is that the matrix from linear package are not
>> compatible with Vector3D.
>> -> This is the main point we wanted to solve by creating a new matrix
>> class.
>> So we have imagined three solutions :
>> a) inherit the RealMatrix, but we need to add a multiply(Vector3D v)
>> method and some other methods
>> b) create an adapter class which contains an Array2DRealMatrix : this
>> may be heavy because we need to implement other methods
>> c) create a rather small class with only a few methods that answer our
>> needs (multiplication with Vector3D, transposition, ...). This class
>> should also implement a specific constructor and a specific getter to
>> fill the gap with the RealMatrix.
>>
>> The other advantage of the c) solution is that it allows to implement
>> faster operations.
>How, exactly, do you expect to be able to improve speed in a way that would not apply to Array2DRowRealMatrix? If there >are faster implementations of the direct array-based operations we should make
>them available to both classes. Having an extra set of matrix ops
>to maintain just for 3x3 matrices does not sound like a happy prospect to me.
>
>Phil
Sorry I made a mistake about the performance of matrix multiplication (see below). Nethertheless, the problem of performance is secondary, since the first reason why we want to add a new Matrix3D class is that the generic implementation is not compliant with Vector3D from geometry.euclidian.threed package.
Here are some observations we made about performance while operating small or big matrix.
We made several tests because in our softwares, we use either small matrix (3x3 or 6x6) to handle position & velocity of a spacecraft or very big matrix (hundreds or thousands of lines & columns) in some orbit restitution tools.
For 3x3 matrix, it's possible to remove the triple loop, by writing directly the 9 sums of products from A & B matrix coefficients. Of course, it's not possible for generic matrix. In our old software in Fortran, it could save about 17% compared to the generic "matmul" intrinsic fonction. We made some benchmark in Java and obtained a gain of about 25%. But the Commons Math implementation is still faster ! And Commons Math is twice as fast as the triple loop implementation.
-> So for small matrix, there's no need to re-code matrix operations
For very big matrix (ie : beyond 500 or 1000 rows/columns), the computation is faster if you transpose the second matrix and then multiply. The two inner loops are inversed and it allows a significant gain for very big matrix (about 40% compared to Commons Math for 1000x1000 matrix, and 50% compared to the classical triple loop). I guess that it's faster for the JVM to access the matrix coefficients in the computer's memory.
Best regards
Yannick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Adding a new class to handle Matrix with 3 columns/rows
Posted by Phil Steitz <ph...@gmail.com>.
On 7/28/11 9:23 AM, Tanguy Yannick wrote:
> On 7/27/11 7:30 AM, Gilles Sadowski wrote:
>>> 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.
>>> Except for the name: "Matrix33" -> "Matrix3D".
> +1 : ok to call it Matrix3D.
>
>>>> [...]
>>>>
>>>>>> 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.
>>>> Yes, we prefer to add a constructor from Array2DRowRealMatrix and a
>>>> getter (that returns a Array2DRowRealMatrix) than to implement the
>>>> whole interface RealMatrix
>>> There are not that many methods. It's preferable to implement
> "RealMatrix"
>>> lest there will be two API eveolving independently.
>> +1
> The key point here is that the matrix from linear package are not
> compatible with Vector3D.
> -> This is the main point we wanted to solve by creating a new matrix
> class.
> So we have imagined three solutions :
> a) inherit the RealMatrix, but we need to add a multiply(Vector3D v)
> method and some other methods
> b) create an adapter class which contains an Array2DRealMatrix : this
> may be heavy because we need to implement other methods
> c) create a rather small class with only a few methods that answer our
> needs (multiplication with Vector3D, transposition, ...). This class
> should also implement a specific constructor and a specific getter to
> fill the gap with the RealMatrix.
>
> The other advantage of the c) solution is that it allows to implement
> faster operations.
How, exactly, do you expect to be able to improve speed in a way
that would not apply to Array2DRowRealMatrix? If there are faster
implementations of the direct array-based operations we should make
them available to both classes. Having an extra set of matrix ops
to maintain just for 3x3 matrices does not sound like a happy
prospect to me.
Phil
>
> Yannick
>
>>> I'm sure that somebody will help implement the missing bits if
> necessary.
>>>> (or inherit the AbstractMatrix).
>>> At the moment, I tend to agree on this point, given what I've just
>>> observed with this benchmark:
>> +1 - the difference is expected, since AbstractRealMatrix has to use
>> getters/setters and Array2DRowRealMatrix can do direct array access. I
> guess to maximize reuse a) the array-based operations could be extracted
> into a static utils class somewhere and used by both impls or b) the new
> class could extend Array2DRowRealMatrix.
>> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Adding a new class to handle Matrix with 3 columns/rows
Posted by Greg Sterijevski <gs...@gmail.com>.
All,
A while back I made a proposal for a SymmetricMatrix class. One of the
problems I encountered is that there is just "too much" in the Matrix
interfaces and abstract classes. In my opinion, pruning the interface would
go a long way to make more of this stuff fit more easily. Since implementing
the current set of interfaces is a bit onerous, you will have this pull to
generate orphan classes or competing class hierarchies...
Going forward I can't help but see much more of these issues. I think there
will be a lots of specializations of matrices and vectors.
-Greg
RE: [math] Adding a new class to handle Matrix with 3 columns/rows
Posted by Tanguy Yannick <Ya...@cnes.fr>.
On 7/27/11 7:30 AM, Gilles Sadowski wrote:
>> 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.
>> Except for the name: "Matrix33" -> "Matrix3D".
+1 : ok to call it Matrix3D.
>>
>>> [...]
>>>
>>>>> 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.
>>> Yes, we prefer to add a constructor from Array2DRowRealMatrix and a
>>> getter (that returns a Array2DRowRealMatrix) than to implement the
>>> whole interface RealMatrix
>> There are not that many methods. It's preferable to implement
"RealMatrix"
>> lest there will be two API eveolving independently.
>
>+1
The key point here is that the matrix from linear package are not
compatible with Vector3D.
-> This is the main point we wanted to solve by creating a new matrix
class.
So we have imagined three solutions :
a) inherit the RealMatrix, but we need to add a multiply(Vector3D v)
method and some other methods
b) create an adapter class which contains an Array2DRealMatrix : this
may be heavy because we need to implement other methods
c) create a rather small class with only a few methods that answer our
needs (multiplication with Vector3D, transposition, ...). This class
should also implement a specific constructor and a specific getter to
fill the gap with the RealMatrix.
The other advantage of the c) solution is that it allows to implement
faster operations.
Yannick
>
>> I'm sure that somebody will help implement the missing bits if
necessary.
>>
>>> (or inherit the AbstractMatrix).
>> At the moment, I tend to agree on this point, given what I've just
>> observed with this benchmark:
>
>+1 - the difference is expected, since AbstractRealMatrix has to use
>getters/setters and Array2DRowRealMatrix can do direct array access. I
guess to maximize reuse a) the array-based operations could be extracted
into a static utils class somewhere and used by both impls or b) the new
class could extend Array2DRowRealMatrix.
>
>Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Adding a new class to handle Matrix with 3 columns/rows
Posted by Phil Steitz <ph...@gmail.com>.
On 7/27/11 7:30 AM, Gilles Sadowski wrote:
> 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.
> Except for the name: "Matrix33" -> "Matrix3D".
>
>> [...]
>>
>>>> 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.
>> Yes, we prefer to add a constructor from Array2DRowRealMatrix and a getter
>> (that returns a Array2DRowRealMatrix) than to implement the whole interface
>> RealMatrix
> There are not that many methods. It's preferable to implement "RealMatrix"
> lest there will be two API eveolving independently.
+1
> I'm sure that somebody will help implement the missing bits if necessary.
>
>> (or inherit the AbstractMatrix).
> At the moment, I tend to agree on this point, given what I've just observed
> with this benchmark:
+1 - the difference is expected, since AbstractRealMatrix has to use
getters/setters and Array2DRowRealMatrix can do direct array
access. I guess to maximize reuse a) the array-based operations
could be extracted into a static utils class somewhere and used by
both impls or b) the new class could extend Array2DRowRealMatrix.
Phil
> ---CUT---
> public void testAddPerf() {
> final Array2DRowRealMatrix mAR = new Array2DRowRealMatrix(testData);
> final RealMatrix mR = mAR;
> final Array2DRowRealMatrix mInv = new Array2DRowRealMatrix(testDataInv);
>
> PerfTestUtils.timeAndReport("add",
> 200,
> 10000,
> new PerfTestUtils.RunTest("RealMatrix") {
> RealMatrix mPlusMInv;
> public void run() {
> mPlusMInv = mR.add(mInv);
> }},
> new PerfTestUtils.RunTest("Array2DRowRealMatrix") {
> RealMatrix mPlusMInv;
> public void run() {
> mPlusMInv = mAR.add(mInv);
> }});
> }
> ---CUT---
>
> The result is:
> ---CUT---
> add
> RealMatrix: 5.722274034999992E-4 ms
> Array2DRowRealMatrix: 4.3001998499999885E-4 ms
> ---CUT---
>
> Thus, in the first "RunTest", it is the (slower) "AbtractRealMatrix.add"
> method that is used, although "mR" is the same object as "mAR" (and an
> instance of "Array2DRowRealMatrix").
>
>> [...]
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Adding a new class to handle Matrix with 3 columns/rows
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
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.
Except for the name: "Matrix33" -> "Matrix3D".
> [...]
>
> >> 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.
>
> Yes, we prefer to add a constructor from Array2DRowRealMatrix and a getter
> (that returns a Array2DRowRealMatrix) than to implement the whole interface
> RealMatrix
There are not that many methods. It's preferable to implement "RealMatrix"
lest there will be two API eveolving independently.
I'm sure that somebody will help implement the missing bits if necessary.
> (or inherit the AbstractMatrix).
At the moment, I tend to agree on this point, given what I've just observed
with this benchmark:
---CUT---
public void testAddPerf() {
final Array2DRowRealMatrix mAR = new Array2DRowRealMatrix(testData);
final RealMatrix mR = mAR;
final Array2DRowRealMatrix mInv = new Array2DRowRealMatrix(testDataInv);
PerfTestUtils.timeAndReport("add",
200,
10000,
new PerfTestUtils.RunTest("RealMatrix") {
RealMatrix mPlusMInv;
public void run() {
mPlusMInv = mR.add(mInv);
}},
new PerfTestUtils.RunTest("Array2DRowRealMatrix") {
RealMatrix mPlusMInv;
public void run() {
mPlusMInv = mAR.add(mInv);
}});
}
---CUT---
The result is:
---CUT---
add
RealMatrix: 5.722274034999992E-4 ms
Array2DRowRealMatrix: 4.3001998499999885E-4 ms
---CUT---
Thus, in the first "RunTest", it is the (slower) "AbtractRealMatrix.add"
method that is used, although "mR" is the same object as "mAR" (and an
instance of "Array2DRowRealMatrix").
> [...]
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [math] Adding a new class to handle Matrix with 3 columns/rows
Posted by Tanguy Yannick <Ya...@cnes.fr>.
Hello Luc and Ted,
Thanks for your comments, see my answers below.
-----Message d'origine-----
De : Luc Maisonobe [mailto:Luc.Maisonobe@free.fr]
Envoyé : mercredi 27 juillet 2011 09:02
À : Commons Developers List
Objet : Re: [math] Adding a new class to handle Matrix with 3 columns/rows
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.
No, we don't need solvers.
>> 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.
Yes, we prefer to add a constructor from Array2DRowRealMatrix and a getter (that returns a Array2DRowRealMatrix) than to implement the whole interface RealMatrix (or inherit the AbstractMatrix).
If some users want to do some complex calculation with a 3x3 Matrix, they can use that getter.
Best regards,
Yannick
>>
>> 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.
>best regards,
>Luc
>
> Yannick TANGUY
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Adding a new class to handle Matrix with 3 columns/rows
Posted by Ted Dunning <te...@gmail.com>.
Constructors? Can't these new matrices implement the current matrix
interface?
On Wed, Jul 27, 2011 at 12:01 AM, Luc Maisonobe <Lu...@free.fr>wrote:
> 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.
RE: [math] Adding a new class to handle Matrix with 3 columns/rows
Posted by Tanguy Yannick <Ya...@cnes.fr>.
-----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
Re: [math] Adding a new class to handle Matrix with 3 columns/rows
Posted by Phil Steitz <ph...@gmail.com>.
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.
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
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Adding a new class to handle Matrix with 3 columns/rows
Posted by Luc Maisonobe <Lu...@free.fr>.
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.
best regards,
Luc
>
> Yannick TANGUY
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org