You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Kim van der Linde <ki...@kimvdlinde.com> on 2004/10/03 04:57:16 UTC
[math] Matrix subMatrix and mean methods
Hi Phil,
I have been thinking for a few days on the Matrix classes.
I think the Matrix class itself should contain all those methods that do
matrix calculations (add, subtract, multiply) that either a Matrix
themselfs or proporties of the Matrix (isSingular for example). The mean
methods (getRowMeans) etc are statistics done ON a matrix, and I think
they should be in a seperate class, maybe called MatrixStats. This
enables aso he option to add variances and SD's which are needed for
column mean resp mean-SD standardizations, to be used for example in PCA
calculations when a covariance resp. correlation matrix is used.
Is there the intention to add an EigenvalueDecomposition class to the
package? In that case, which algorithm is targeted to be used? Jacobi?
Cheers,
Kim
--
http://www.kimvdlinde.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Matrix subMatrix and mean methods
Posted by Al Chou <ho...@yahoo.com>.
--- "Mark R. Diggory" <md...@latte.harvard.edu> wrote:
> Al Chou wrote:
> >
> > I agree we should not be releasing Apache versions of the whole Colt
> library
> > (which technically wouldn't even be possible, as the hep.aida.* packages
> are
> > LGPL'd, not under the the new CERN license). In any case, the question of
> the
> > scope of Commons-Math continually comes up, and the merging in of Colt is
> yet
> > another impetus for discussing it. If we were to include large portions or
> all
> > of the CERN-licensed code of Colt, we would be in a position to claim a
> much
> > larger scope/charter for the project. But would we want to? Some project
> > members seem very interested in doing so (and I am certainly guilty of such
> > thoughts), but I don't think it necessarily makes sense. Commons-Math's
> > charter is a sound one, and I would not want to alienate/inconvenience
> users
> > whose needs are well met by its current scope and charter (assuming there
> are
> > any such) by increasing it unnecessarily. A separate project would
> probably be
> > more appropriate if we wanted a larger scope.
> >
> >
> > Al
>
> Al,
>
> I really agree that "merging" or adding much of the code from Colt can
> result in a project outside the scope of Commons Math. (Not that this
> can't stop us from using portions of it within Commons Math initially,
> which I promote). I really perceive the need for a parent project that
> manages numerical and mathematical codebases that are considered to be
> outside the scope of Commons Math.
>
> I agree that there are concerns with the hep LGPL packages and suspect
> they would not be allowed into Apache due to these concerns.
Yes, I agree that Colt has much that would be useful to us in Commons Math,
e.g., templated multi-dimensional matrices, both dense and sparse. But we
should draw a boundary somewhere that Commons Math should not cross as we
incorporate Colt code. For instance, I suspect most Java server-side
programmers will need special functions beyond what we already provide (largely
just to support our statistics functionality). However, the function objects
in that same package are intriguing and possibly quite useful to us and our
users. I think a minority of classes from cern.jet.random would be valuable,
the rest being too advanced for our scope. The templated lists and maps look
neat, but I don't know whether we really need them, nor whether Commons Math is
really the place for them anyway (somewhere else in Commons may make sense, say
Lang?). And the concurrent programming stuff is really for high performance
computing, which I'd say is out of scope for Commons Math.
Surprisingly, I think I've just drawn the boundary, at a high level. Or at
least a straw man proposal of one. Thoughts?
Al
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Matrix subMatrix and mean methods
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Al Chou wrote:
>
> I agree we should not be releasing Apache versions of the whole Colt library
> (which technically wouldn't even be possible, as the hep.aida.* packages are
> LGPL'd, not under the the new CERN license). In any case, the question of the
> scope of Commons-Math continually comes up, and the merging in of Colt is yet
> another impetus for discussing it. If we were to include large portions or all
> of the CERN-licensed code of Colt, we would be in a position to claim a much
> larger scope/charter for the project. But would we want to? Some project
> members seem very interested in doing so (and I am certainly guilty of such
> thoughts), but I don't think it necessarily makes sense. Commons-Math's
> charter is a sound one, and I would not want to alienate/inconvenience users
> whose needs are well met by its current scope and charter (assuming there are
> any such) by increasing it unnecessarily. A separate project would probably be
> more appropriate if we wanted a larger scope.
>
>
> Al
Al,
I really agree that "merging" or adding much of the code from Colt can
result in a project outside the scope of Commons Math. (Not that this
can't stop us from using portions of it within Commons Math initially,
which I promote). I really perceive the need for a parent project that
manages numerical and mathematical codebases that are considered to be
outside the scope of Commons Math.
I agree that there are concerns with the hep LGPL packages and suspect
they would not be allowed into Apache due to these concerns.
-Mark
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Matrix subMatrix and mean methods
Posted by Al Chou <ho...@yahoo.com>.
--- "Mark R. Diggory" <md...@apache.org> wrote:
> Wolfgang Hoschek wrote:
> > Mark,
> >
> > I am not worried about "fracturing". My understanding is that you
> > wouldn't start doing colt releases build by apache, right? You'd rather
> > take some parts or derivatives of the code and add them to commons-math
> > CVS as you see fit (probably in a significantly refactored/modified
> > form). I thought that was the overall idea, and it seems to me a good one.
>
> We have discussed a "Larger" project at Apache that would be more
> "expansive" than what is currently capable in the "Jakarta Commons".
> Whether or not such a project takes off has been limited more by
> uncertainty of what its "boundaries" would be.
>
> > If all goes well, Colt as an external library could fade into oblivion
> > in a year or two, or whatever time it takes for math to really shape up.
> > That's absolutely fine with me.
>
> Do you suspect that you or CERN will maintain historical archiving of
> the Colt project indefinitely if it did? This is one of the
> characteristics of ASF, we maintain historical CVS and distribution
> archives for all the projects that have existed in Apache. So, if Colt
> moved into Apache, it would have a long term, canonical archival home
> for its existence even if it's contents were integrated into Apache
> Math. If it was not your interest to maintain it any longer, then such
> an option would be beneficial for the both historical referencing and
> reusage.
> >
> > As far as myself as project member/committer: Thanks for the kind
> > invitation, but I'm really busy with other things these days. However, I
> > can be there for you in case you'd have questions about how/why things
> > work "the way they work" in colt. To reach me, please make sure to "cc"
> > me; commons-dev is a high volume mailing list.
>
> Of course, we would enjoy any involvement you can provide. I understand
> your career focus may be in different directions now.
>
> > I have no particular opinion on (A), it's up to you.
> >
> > B) sounds confusing to me as it might indicate to users that they should
> > use that library instead of commons-math. Why have a jakarta level
> > project if all you want is to take some parts or derivatives of it and
> > integrate them in "math"?
> >
> > Regards,
> > Wolfgang.
> >
>
> Codebases have been donated to Apache Jakarta in the past which maintain
> similar capabilities. For instance, Oro and Apache Regexp were projects
> from different development groups, the code donation was to, in my
> belief, provide a mechanism to merge these projects at a time in the
> future, taking the best of both worlds.
>
> http://jakarta.apache.org/oro/index.html
> http://jakarta.apache.org/regexp/index.html
>
> I do adimately believe we would not want to consider releasing a full
> version of Colt unless you were interested in migrating the entire
> project into Apache, this is what I mean by fracturing, we do not want
> to see two separate "Colt" communities competing for membership, this
> would not be in either of our interests, would confuse the userbase and
> not allow us to build a "shared" development community.
I agree we should not be releasing Apache versions of the whole Colt library
(which technically wouldn't even be possible, as the hep.aida.* packages are
LGPL'd, not under the the new CERN license). In any case, the question of the
scope of Commons-Math continually comes up, and the merging in of Colt is yet
another impetus for discussing it. If we were to include large portions or all
of the CERN-licensed code of Colt, we would be in a position to claim a much
larger scope/charter for the project. But would we want to? Some project
members seem very interested in doing so (and I am certainly guilty of such
thoughts), but I don't think it necessarily makes sense. Commons-Math's
charter is a sound one, and I would not want to alienate/inconvenience users
whose needs are well met by its current scope and charter (assuming there are
any such) by increasing it unnecessarily. A separate project would probably be
more appropriate if we wanted a larger scope.
Al
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Matrix subMatrix and mean methods
Posted by "Mark R. Diggory" <md...@apache.org>.
Wolfgang Hoschek wrote:
> Mark,
>
> I am not worried about "fracturing". My understanding is that you
> wouldn't start doing colt releases build by apache, right? You'd rather
> take some parts or derivatives of the code and add them to commons-math
> CVS as you see fit (probably in a significantly refactored/modified
> form). I thought that was the overall idea, and it seems to me a good one.
We have discussed a "Larger" project at Apache that would be more
"expansive" than what is currently capable in the "Jakarta Commons".
Whether or not such a project takes off has been limited more by
uncertainty of what its "boundaries" would be.
> If all goes well, Colt as an external library could fade into oblivion
> in a year or two, or whatever time it takes for math to really shape up.
> That's absolutely fine with me.
Do you suspect that you or CERN will maintain historical archiving of
the Colt project indefinitely if it did? This is one of the
characteristics of ASF, we maintain historical CVS and distribution
archives for all the projects that have existed in Apache. So, if Colt
moved into Apache, it would have a long term, canonical archival home
for its existence even if it's contents were integrated into Apache
Math. If it was not your interest to maintain it any longer, then such
an option would be beneficial for the both historical referencing and
reusage.
>
> As far as myself as project member/committer: Thanks for the kind
> invitation, but I'm really busy with other things these days. However, I
> can be there for you in case you'd have questions about how/why things
> work "the way they work" in colt. To reach me, please make sure to "cc"
> me; commons-dev is a high volume mailing list.
Of course, we would enjoy any involvement you can provide. I understand
your career focus may be in different directions now.
> I have no particular opinion on (A), it's up to you.
>
> B) sounds confusing to me as it might indicate to users that they should
> use that library instead of commons-math. Why have a jakarta level
> project if all you want is to take some parts or derivatives of it and
> integrate them in "math"?
>
> Regards,
> Wolfgang.
>
Codebases have been donated to Apache Jakarta in the past which maintain
similar capabilities. For instance, Oro and Apache Regexp were projects
from different development groups, the code donation was to, in my
belief, provide a mechanism to merge these projects at a time in the
future, taking the best of both worlds.
http://jakarta.apache.org/oro/index.html
http://jakarta.apache.org/regexp/index.html
I do adimately believe we would not want to consider releasing a full
version of Colt unless you were interested in migrating the entire
project into Apache, this is what I mean by fracturing, we do not want
to see two separate "Colt" communities competing for membership, this
would not be in either of our interests, would confuse the userbase and
not allow us to build a "shared" development community.
thanks,
Mark
--
Mark Diggory
Open Source Software Developer
Apache Jakarta Project
http://jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Matrix subMatrix and mean methods
Posted by Wolfgang Hoschek <wh...@lbl.gov>.
Mark,
I am not worried about "fracturing". My understanding is that you
wouldn't start doing colt releases build by apache, right? You'd rather
take some parts or derivatives of the code and add them to commons-math
CVS as you see fit (probably in a significantly refactored/modified
form). I thought that was the overall idea, and it seems to me a good
one.
If all goes well, Colt as an external library could fade into oblivion
in a year or two, or whatever time it takes for math to really shape
up. That's absolutely fine with me.
As far as myself as project member/committer: Thanks for the kind
invitation, but I'm really busy with other things these days. However,
I can be there for you in case you'd have questions about how/why
things work "the way they work" in colt. To reach me, please make sure
to "cc" me; commons-dev is a high volume mailing list.
I have no particular opinion on (A), it's up to you.
B) sounds confusing to me as it might indicate to users that they
should use that library instead of commons-math. Why have a jakarta
level project if all you want is to take some parts or derivatives of
it and integrate them in "math"?
Regards,
Wolfgang.
Mark, see comments inline below:
On Oct 8, 2004, at 7:19 AM, Mark R. Diggory wrote:
> Brain and Wolfgang,
>
> This sort of clarification is exactly what we needed to hear. It
> sounds like we can begin working portions of Colt now.
>
> My question to Wolfgang is, to avoid "fracturing" Colt into multiple
> implementations, we could decided between two possible approaches.
>
> A.) Refer to the portions of Colt we may be using by pointing to the
> external Colt project where ever necessary without actually placing
> the entire package into the Apache CVS tree.
>
> or
>
> B.) Explore the idea of Colt as an actual "Jakarta" level project and
> invite Wolfgang to join us as a member of that project development
> team.
>
> Wolfgang, what do you think?
>
> thanks,
> -Mark
>
> Brian Behlendorf wrote:
>> On Thu, 7 Oct 2004, Phil Steitz wrote:
>>> Brian Behlendorf wrote:
>>>
>>>>
>>>> Thanks, Wolfgang. This is a pretty easy case for us - as it sits
>>>> today, especially with this email note from Wolfgang (which should
>>>> be included in a NOTES file sitting near colt.jar when imported) it
>>>> looks perfectly fine to incorporate this into Apache, preserving
>>>> CERN's copyright notice. From a policy perspective, we should
>>>> commit to the repository not just the .jar file but the source code
>>>> as well.
>>>>
>>>> Any patches that Apache developers need to make should be offered
>>>> upstream, of course, and then reincorporated into the ASF
>>>> repository by merging in a new version. But if we need to locally
>>>> modify the work, then the copyright on the resulting derivative
>>>> work would be (C) Apache Software Foundation and the Apache 2.0
>>>> license, being careful not to remove the original (C) CERN or
>>>> license/notice.
>>>
>>>
>>> What if what we end up wanting to do is to incorporate code from the
>>> implemented algorithms into existing Apache software? Then do we
>>> just need to add the CERN license / notice?
>> You should include the CERN license into the file where the code that
>> originated from CERN appeared, making it clear that it refers to the
>> code that was imported. For example, at the top of the related file:
>> /* Copyright 1999-2004 The Apache Software Foundation
>> *
>> * Licensed under the Apache License, Version 2.0 (the "License");
>> * you may not use this file except in compliance with the License.
>> * You may obtain a copy of the License at
>> *
>> * http://www.apache.org/licenses/LICENSE-2.0
>> *
>> * Unless required by applicable law or agreed to in writing, software
>> * distributed under the License is distributed on an "AS IS" BASIS,
>> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
>> implied.
>> * See the License for the specific language governing permissions and
>> * limitations under the License.
>> */
>> /* Portions originally Copyright CERN, under the following license:
>> * [... CERN license ...]
>> */
>> The CVS or SVN history would be consulted if we needed to know
>> exactly which portions. The above is enough to know - it gives
>> credit where credit is due, and nothing in that license places a
>> requirement that the ASF license does not also require.
>> Brian
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
> --
> Mark Diggory
> Open Source Software Developer
> Apache Jakarta Project
> http://jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Matrix subMatrix and mean methods
Posted by "Mark R. Diggory" <md...@apache.org>.
Brain and Wolfgang,
This sort of clarification is exactly what we needed to hear. It sounds
like we can begin working portions of Colt now.
My question to Wolfgang is, to avoid "fracturing" Colt into multiple
implementations, we could decided between two possible approaches.
A.) Refer to the portions of Colt we may be using by pointing to the
external Colt project where ever necessary without actually placing the
entire package into the Apache CVS tree.
or
B.) Explore the idea of Colt as an actual "Jakarta" level project and
invite Wolfgang to join us as a member of that project development team.
Wolfgang, what do you think?
thanks,
-Mark
Brian Behlendorf wrote:
> On Thu, 7 Oct 2004, Phil Steitz wrote:
>
>> Brian Behlendorf wrote:
>>
>>>
>>> Thanks, Wolfgang. This is a pretty easy case for us - as it sits
>>> today, especially with this email note from Wolfgang (which should be
>>> included in a NOTES file sitting near colt.jar when imported) it
>>> looks perfectly fine to incorporate this into Apache, preserving
>>> CERN's copyright notice. From a policy perspective, we should commit
>>> to the repository not just the .jar file but the source code as well.
>>>
>>> Any patches that Apache developers need to make should be offered
>>> upstream, of course, and then reincorporated into the ASF repository
>>> by merging in a new version. But if we need to locally modify the
>>> work, then the copyright on the resulting derivative work would be
>>> (C) Apache Software Foundation and the Apache 2.0 license, being
>>> careful not to remove the original (C) CERN or license/notice.
>>
>>
>> What if what we end up wanting to do is to incorporate code from the
>> implemented algorithms into existing Apache software? Then do we just
>> need to add the CERN license / notice?
>
>
> You should include the CERN license into the file where the code that
> originated from CERN appeared, making it clear that it refers to the
> code that was imported. For example, at the top of the related file:
>
> /* Copyright 1999-2004 The Apache Software Foundation
> *
> * Licensed under the Apache License, Version 2.0 (the "License");
> * you may not use this file except in compliance with the License.
> * You may obtain a copy of the License at
> *
> * http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
>
> /* Portions originally Copyright CERN, under the following license:
> * [... CERN license ...]
> */
>
> The CVS or SVN history would be consulted if we needed to know exactly
> which portions. The above is enough to know - it gives credit where
> credit is due, and nothing in that license places a requirement that the
> ASF license does not also require.
>
> Brian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
Mark Diggory
Open Source Software Developer
Apache Jakarta Project
http://jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Matrix subMatrix and mean methods
Posted by Brian Behlendorf <br...@collab.net>.
On Thu, 7 Oct 2004, Phil Steitz wrote:
> Brian Behlendorf wrote:
>>
>> Thanks, Wolfgang. This is a pretty easy case for us - as it sits today,
>> especially with this email note from Wolfgang (which should be included in
>> a NOTES file sitting near colt.jar when imported) it looks perfectly fine
>> to incorporate this into Apache, preserving CERN's copyright notice. From a
>> policy perspective, we should commit to the repository not just the .jar
>> file but the source code as well.
>>
>> Any patches that Apache developers need to make should be offered upstream,
>> of course, and then reincorporated into the ASF repository by merging in a
>> new version. But if we need to locally modify the work, then the copyright
>> on the resulting derivative work would be (C) Apache Software Foundation
>> and the Apache 2.0 license, being careful not to remove the original (C)
>> CERN or license/notice.
>
> What if what we end up wanting to do is to incorporate code from the
> implemented algorithms into existing Apache software? Then do we just need
> to add the CERN license / notice?
You should include the CERN license into the file where the code that
originated from CERN appeared, making it clear that it refers to the code
that was imported. For example, at the top of the related file:
/* Copyright 1999-2004 The Apache Software Foundation
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
/* Portions originally Copyright CERN, under the following license:
* [... CERN license ...]
*/
The CVS or SVN history would be consulted if we needed to know exactly
which portions. The above is enough to know - it gives credit where
credit is due, and nothing in that license places a requirement that the
ASF license does not also require.
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Matrix subMatrix and mean methods
Posted by Phil Steitz <ph...@steitz.com>.
Brian Behlendorf wrote:
>
> Thanks, Wolfgang. This is a pretty easy case for us - as it sits today,
> especially with this email note from Wolfgang (which should be included
> in a NOTES file sitting near colt.jar when imported) it looks perfectly
> fine to incorporate this into Apache, preserving CERN's copyright
> notice. From a policy perspective, we should commit to the repository
> not just the .jar file but the source code as well.
>
> Any patches that Apache developers need to make should be offered
> upstream, of course, and then reincorporated into the ASF repository by
> merging in a new version. But if we need to locally modify the work,
> then the copyright on the resulting derivative work would be (C) Apache
> Software Foundation and the Apache 2.0 license, being careful not to
> remove the original (C) CERN or license/notice.
Brian,
What if what we end up wanting to do is to incorporate code from the
implemented algorithms into existing Apache software? Then do we just
need to add the CERN license / notice?
thx,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Matrix subMatrix and mean methods
Posted by Brian Behlendorf <br...@collab.net>.
On Thu, 7 Oct 2004, Mark R. Diggory wrote:
> After being reminded by Wolfgang that he had previously given me a contact at
> CERN to discuss these issues with, I emailed that contact. He forwarded me to
> the Technology Transfer officer for CERN. I just finished emailing a request
> to that individual to comment on the position CERN holds on this subject of
> relicensing/donation. Once we hear back from them we can also include this
> information into the discussion. I expect it will clarify if any opposition
> does exist at the original institution.
OK, but the existing license is fine - no further clarification or
permissions from CERN should be needed.
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Matrix subMatrix and mean methods
Posted by "Mark R. Diggory" <md...@apache.org>.
Hi Brian,
After being reminded by Wolfgang that he had previously given me a
contact at CERN to discuss these issues with, I emailed that contact. He
forwarded me to the Technology Transfer officer for CERN. I just
finished emailing a request to that individual to comment on the
position CERN holds on this subject of relicensing/donation. Once we
hear back from them we can also include this information into the
discussion. I expect it will clarify if any opposition does exist at the
original institution.
Cheers,
Mark
Brian Behlendorf wrote:
>
> Thanks, Wolfgang. This is a pretty easy case for us - as it sits today,
> especially with this email note from Wolfgang (which should be included
> in a NOTES file sitting near colt.jar when imported) it looks perfectly
> fine to incorporate this into Apache, preserving CERN's copyright
> notice. From a policy perspective, we should commit to the repository
> not just the .jar file but the source code as well.
>
> Any patches that Apache developers need to make should be offered
> upstream, of course, and then reincorporated into the ASF repository by
> merging in a new version. But if we need to locally modify the work,
> then the copyright on the resulting derivative work would be (C) Apache
> Software Foundation and the Apache 2.0 license, being careful not to
> remove the original (C) CERN or license/notice.
>
> Brian
>
> On Tue, 5 Oct 2004, Wolfgang Hoschek wrote:
>
>> Hi, let me briefly introduce myself. I'm the author of Colt which has
>> the BSD-style license you referred to below.
>>
>> I encourage you to take code or ideas from Colt, as you see fit, and
>> as you see compatible with Apache licensing policy.
>> I wrote this code some six years ago while working at CERN, so the
>> copyright is not with me personally, but with CERN
>> (http://www.cern.ch). I have left CERN some years ago to work for a
>> Bay Area research lab, so I consider it unlikely that the license
>> could be changed, and I'm not in a position to help change the
>> license, even though I would support such a license change. In my
>> judgement, you will have to decide if the current license works for
>> you, or not. If it works for you, you are most welcome.
>>
>> As far as Jama is concerned, the code is a straightforward adaption of
>> the original Jama code, as explained on
>> http://dsd.lbl.gov/~hoschek/colt/api/cern/colt/matrix/linalg/package-
>> summary.html#Overview
>> You could contact the Jama authors for licensing issues.
>>
>> Hope this helps,
>> Wolfgang.
>>
>>> I am posting this to the Licensing list as well because it is very
>>> unclear how to proceed and we dearly need their advice on this
>>> subject. Licensing, the issue has to do with policy for adding code
>>> from a external project, which the author has approved our usage of
>>> via email.
>>>
>>> http://www.theserverside.com/news/thread.tss?thread_id=28596#137409
>>> /www.mail-archive.com/commons-dev@jakarta.apache.org/msg48417.html
>>>
>>> We would like to add certain fragments of the "Colt" API which is
>>> licensed under a BSD style licensing.
>>>
>>> http://dsd.lbl.gov/~hoschek/colt/license.html
>>>
>>> How do we properly proceed?
>>>
>>> Al Chou wrote:
>>>
>>>> Colt contains a port of much of JAMA, IIRC, and as Wolfgang posted
>>>> not too long
>>>> ago, Colt's new license is much more compatible with the Apache
>>>> license. I'm
>>>> not sure if it's sufficiently compatible for us to start merging in
>>>> code,
>>>> though.
>>>> Al
>>>
>>>
>>> I think we should clarify our own position given his approval.
>>>
>>> 1.) I think the appropriate path is to discuss with Wolfgang and our
>>> Licensing list what is required to meet any ASF requirements that may
>>> exist. Licensing needs to clarify how we should proceed.
>>>
>>> The challenge is what to do about any ASF polices concerning
>>> licensing adjustments, for which none of us are "knowledgeable".
>>>
>>> 2.) I think this is a exception to our policy of acknowledging
>>> authorship in the project documentation and not in the code. In this
>>> case I think we should attempt to maintain significant references to
>>> his project as the original source of any codebase additions added to
>>> the Commons math API.
>>>
>>> 3.) If ASF requires more stringent approval in writing, we request
>>> more formally to have Wolfgang fax in some sort of donation form to ASF.
>>>
>>> -Mark
>>>
>>> --
>>> Mark Diggory
>>> Software Developer
>>> Harvard MIT Data Center
>>> http://www.hmdc.harvard.edu
>>
>>
>>
>> -----------------------------------------------------------------------
>> Wolfgang Hoschek | email: whoschek@lbl.gov
>> Distributed Systems Department | phone: (415)-533-7610
>> Berkeley Laboratory | http://dsd.lbl.gov/~hoschek/
>> -----------------------------------------------------------------------
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: licensing-unsubscribe@apache.org
>> For additional commands, e-mail: licensing-help@apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
Mark Diggory
Open Source Software Developer
Apache Jakarta Project
http://jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Matrix subMatrix and mean methods
Posted by Brian Behlendorf <br...@collab.net>.
Thanks, Wolfgang. This is a pretty easy case for us - as it sits today,
especially with this email note from Wolfgang (which should be included in
a NOTES file sitting near colt.jar when imported) it looks perfectly fine
to incorporate this into Apache, preserving CERN's copyright notice.
>From a policy perspective, we should commit to the repository not just the
.jar file but the source code as well.
Any patches that Apache developers need to make should be offered
upstream, of course, and then reincorporated into the ASF repository by
merging in a new version. But if we need to locally modify the work,
then the copyright on the resulting derivative work would be (C) Apache
Software Foundation and the Apache 2.0 license, being careful not to
remove the original (C) CERN or license/notice.
Brian
On Tue, 5 Oct 2004, Wolfgang Hoschek wrote:
> Hi, let me briefly introduce myself. I'm the author of Colt which has the
> BSD-style license you referred to below.
>
> I encourage you to take code or ideas from Colt, as you see fit, and as you
> see compatible with Apache licensing policy.
> I wrote this code some six years ago while working at CERN, so the copyright
> is not with me personally, but with CERN (http://www.cern.ch). I have left
> CERN some years ago to work for a Bay Area research lab, so I consider it
> unlikely that the license could be changed, and I'm not in a position to help
> change the license, even though I would support such a license change. In my
> judgement, you will have to decide if the current license works for you, or
> not. If it works for you, you are most welcome.
>
> As far as Jama is concerned, the code is a straightforward adaption of the
> original Jama code, as explained on
> http://dsd.lbl.gov/~hoschek/colt/api/cern/colt/matrix/linalg/package-
> summary.html#Overview
> You could contact the Jama authors for licensing issues.
>
> Hope this helps,
> Wolfgang.
>
>> I am posting this to the Licensing list as well because it is very unclear
>> how to proceed and we dearly need their advice on this subject. Licensing,
>> the issue has to do with policy for adding code from a external project,
>> which the author has approved our usage of via email.
>>
>> http://www.theserverside.com/news/thread.tss?thread_id=28596#137409
>> /www.mail-archive.com/commons-dev@jakarta.apache.org/msg48417.html
>>
>> We would like to add certain fragments of the "Colt" API which is licensed
>> under a BSD style licensing.
>>
>> http://dsd.lbl.gov/~hoschek/colt/license.html
>>
>> How do we properly proceed?
>>
>> Al Chou wrote:
>>
>>> Colt contains a port of much of JAMA, IIRC, and as Wolfgang posted not too
>>> long
>>> ago, Colt's new license is much more compatible with the Apache license.
>>> I'm
>>> not sure if it's sufficiently compatible for us to start merging in code,
>>> though.
>>> Al
>>
>> I think we should clarify our own position given his approval.
>>
>> 1.) I think the appropriate path is to discuss with Wolfgang and our
>> Licensing list what is required to meet any ASF requirements that may
>> exist. Licensing needs to clarify how we should proceed.
>>
>> The challenge is what to do about any ASF polices concerning licensing
>> adjustments, for which none of us are "knowledgeable".
>>
>> 2.) I think this is a exception to our policy of acknowledging authorship
>> in the project documentation and not in the code. In this case I think we
>> should attempt to maintain significant references to his project as the
>> original source of any codebase additions added to the Commons math API.
>>
>> 3.) If ASF requires more stringent approval in writing, we request more
>> formally to have Wolfgang fax in some sort of donation form to ASF.
>>
>> -Mark
>>
>> --
>> Mark Diggory
>> Software Developer
>> Harvard MIT Data Center
>> http://www.hmdc.harvard.edu
>
>
> -----------------------------------------------------------------------
> Wolfgang Hoschek | email: whoschek@lbl.gov
> Distributed Systems Department | phone: (415)-533-7610
> Berkeley Laboratory | http://dsd.lbl.gov/~hoschek/
> -----------------------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: licensing-unsubscribe@apache.org
> For additional commands, e-mail: licensing-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Matrix subMatrix and mean methods
Posted by "Mark R. Diggory" <md...@apache.org>.
Hello Wolfgang,
You jogged my memory concerning our discussion on this subject some time
ago. You had given me a contact (James Casey) at CERN to discuss this
subject further and I think the subject slipped off the radar at that
point. Here was that old thread. I've cc'd him on this message to
re-initialize discussion.
-Mark
> James Casey wrote:
>
>> Hi guys,
>>
>> Wolfgang Hoschek wrote:
>>
>>> Mark, James:
>>>
>>> Mark: James Casey at CERN is fluent in java /
>>> open source. I'm cc'ing him here.
>>>
>>> James: On behalf of jakarta-commons-math, Mark would like to
>>> discuss if and how parts of colt could be relicensed under the ASF
>>> license so that commons can work from there. See
>>>
>>> James, if you'd like to help Mark and the jakarta-commons folks
>>> out, please let him know what if anything could be done about
>>> relicensing and/or copyright transfers. See Marks suggestions to
>>> keep CERN's name and origin in there, somewhere.
>>>
>> I saw this come up on the jpackage list a week or so ago... I'd love
>> to do what I can to help. I'll try and find the appropriate person
>> in CERN legal for you to contact (We have some contacts from doing
>> the EDG licence).
Wolfgang Hoschek wrote:
> Hi, let me briefly introduce myself. I'm the author of Colt which has
> the BSD-style license you referred to below.
>
> I encourage you to take code or ideas from Colt, as you see fit, and as
> you see compatible with Apache licensing policy.
> I wrote this code some six years ago while working at CERN, so the
> copyright is not with me personally, but with CERN
> (http://www.cern.ch). I have left CERN some years ago to work for a Bay
> Area research lab, so I consider it unlikely that the license could be
> changed, and I'm not in a position to help change the license, even
> though I would support such a license change. In my judgement, you will
> have to decide if the current license works for you, or not. If it
> works for you, you are most welcome.
>
> As far as Jama is concerned, the code is a straightforward adaption of
> the original Jama code, as explained on
> http://dsd.lbl.gov/~hoschek/colt/api/cern/colt/matrix/linalg/package-
> summary.html#Overview
> You could contact the Jama authors for licensing issues.
>
> Hope this helps,
> Wolfgang.
>
>> I am posting this to the Licensing list as well because it is very
>> unclear how to proceed and we dearly need their advice on this
>> subject. Licensing, the issue has to do with policy for adding code
>> from a external project, which the author has approved our usage of
>> via email.
>>
>> http://www.theserverside.com/news/thread.tss?thread_id=28596#137409
>> /www.mail-archive.com/commons-dev@jakarta.apache.org/msg48417.html
>>
>> We would like to add certain fragments of the "Colt" API which is
>> licensed under a BSD style licensing.
>>
>> http://dsd.lbl.gov/~hoschek/colt/license.html
>>
>> How do we properly proceed?
>>
>> Al Chou wrote:
>>
>>> Colt contains a port of much of JAMA, IIRC, and as Wolfgang posted
>>> not too long
>>> ago, Colt's new license is much more compatible with the Apache
>>> license. I'm
>>> not sure if it's sufficiently compatible for us to start merging in
>>> code,
>>> though.
>>> Al
>>
>>
>> I think we should clarify our own position given his approval.
>>
>> 1.) I think the appropriate path is to discuss with Wolfgang and our
>> Licensing list what is required to meet any ASF requirements that may
>> exist. Licensing needs to clarify how we should proceed.
>>
>> The challenge is what to do about any ASF polices concerning
>> licensing adjustments, for which none of us are "knowledgeable".
>>
>> 2.) I think this is a exception to our policy of acknowledging
>> authorship in the project documentation and not in the code. In this
>> case I think we should attempt to maintain significant references to
>> his project as the original source of any codebase additions added to
>> the Commons math API.
>>
>> 3.) If ASF requires more stringent approval in writing, we request
>> more formally to have Wolfgang fax in some sort of donation form to ASF.
>>
>> -Mark
>>
>> --
>> Mark Diggory
>> Software Developer
>> Harvard MIT Data Center
>> http://www.hmdc.harvard.edu
>
>
>
> -----------------------------------------------------------------------
> Wolfgang Hoschek | email: whoschek@lbl.gov
> Distributed Systems Department | phone: (415)-533-7610
> Berkeley Laboratory | http://dsd.lbl.gov/~hoschek/
> -----------------------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
Mark Diggory
Open Source Software Developer
Apache Jakarta Project
http://jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Matrix subMatrix and mean methods
Posted by Wolfgang Hoschek <wh...@lbl.gov>.
Hi, let me briefly introduce myself. I'm the author of Colt which has
the BSD-style license you referred to below.
I encourage you to take code or ideas from Colt, as you see fit, and as
you see compatible with Apache licensing policy.
I wrote this code some six years ago while working at CERN, so the
copyright is not with me personally, but with CERN
(http://www.cern.ch). I have left CERN some years ago to work for a Bay
Area research lab, so I consider it unlikely that the license could be
changed, and I'm not in a position to help change the license, even
though I would support such a license change. In my judgement, you will
have to decide if the current license works for you, or not. If it
works for you, you are most welcome.
As far as Jama is concerned, the code is a straightforward adaption of
the original Jama code, as explained on
http://dsd.lbl.gov/~hoschek/colt/api/cern/colt/matrix/linalg/package-
summary.html#Overview
You could contact the Jama authors for licensing issues.
Hope this helps,
Wolfgang.
> I am posting this to the Licensing list as well because it is very
> unclear how to proceed and we dearly need their advice on this
> subject. Licensing, the issue has to do with policy for adding code
> from a external project, which the author has approved our usage of
> via email.
>
> http://www.theserverside.com/news/thread.tss?thread_id=28596#137409
> /www.mail-archive.com/commons-dev@jakarta.apache.org/msg48417.html
>
> We would like to add certain fragments of the "Colt" API which is
> licensed under a BSD style licensing.
>
> http://dsd.lbl.gov/~hoschek/colt/license.html
>
> How do we properly proceed?
>
> Al Chou wrote:
>
>> Colt contains a port of much of JAMA, IIRC, and as Wolfgang posted
>> not too long
>> ago, Colt's new license is much more compatible with the Apache
>> license. I'm
>> not sure if it's sufficiently compatible for us to start merging in
>> code,
>> though.
>> Al
>
> I think we should clarify our own position given his approval.
>
> 1.) I think the appropriate path is to discuss with Wolfgang and our
> Licensing list what is required to meet any ASF requirements that may
> exist. Licensing needs to clarify how we should proceed.
>
> The challenge is what to do about any ASF polices concerning licensing
> adjustments, for which none of us are "knowledgeable".
>
> 2.) I think this is a exception to our policy of acknowledging
> authorship in the project documentation and not in the code. In this
> case I think we should attempt to maintain significant references to
> his project as the original source of any codebase additions added to
> the Commons math API.
>
> 3.) If ASF requires more stringent approval in writing, we request
> more formally to have Wolfgang fax in some sort of donation form to
> ASF.
>
> -Mark
>
> --
> Mark Diggory
> Software Developer
> Harvard MIT Data Center
> http://www.hmdc.harvard.edu
-----------------------------------------------------------------------
Wolfgang Hoschek | email: whoschek@lbl.gov
Distributed Systems Department | phone: (415)-533-7610
Berkeley Laboratory | http://dsd.lbl.gov/~hoschek/
-----------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Matrix subMatrix and mean methods
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
I am posting this to the Licensing list as well because it is very
unclear how to proceed and we dearly need their advice on this subject.
Licensing, the issue has to do with policy for adding code from a
external project, which the author has approved our usage of via email.
http://www.theserverside.com/news/thread.tss?thread_id=28596#137409
/www.mail-archive.com/commons-dev@jakarta.apache.org/msg48417.html
We would like to add certain fragments of the "Colt" API which is
licensed under a BSD style licensing.
http://dsd.lbl.gov/~hoschek/colt/license.html
How do we properly proceed?
Al Chou wrote:
>
> Colt contains a port of much of JAMA, IIRC, and as Wolfgang posted not too long
> ago, Colt's new license is much more compatible with the Apache license. I'm
> not sure if it's sufficiently compatible for us to start merging in code,
> though.
>
>
> Al
>
I think we should clarify our own position given his approval.
1.) I think the appropriate path is to discuss with Wolfgang and our
Licensing list what is required to meet any ASF requirements that may
exist. Licensing needs to clarify how we should proceed.
The challenge is what to do about any ASF polices concerning licensing
adjustments, for which none of us are "knowledgeable".
2.) I think this is a exception to our policy of acknowledging
authorship in the project documentation and not in the code. In this
case I think we should attempt to maintain significant references to his
project as the original source of any codebase additions added to the
Commons math API.
3.) If ASF requires more stringent approval in writing, we request more
formally to have Wolfgang fax in some sort of donation form to ASF.
-Mark
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Matrix subMatrix and mean methods
Posted by Al Chou <ho...@yahoo.com>.
--- Kim van der Linde <ki...@kimvdlinde.com> wrote:
> Phil Steitz wrote:
>
> > I agree here as well. Do you see use cases where you will want to start
> > with a double[][] array, perform matrix operations on it (say some
> > decomposition) and then run stats on the resulting matrix? Will it be
> > too onerous to make copies of the double[][] at each stage? If so, we
> > need to think about access to the double[][].
>
> I think keeping getData() will do the job. I generally do not like to
> store the result of a calculation in the original matrix, it always
> confuses me. If the content is of a different type, the name should be
> different.
>
> >> Is there the intention to add an EigenvalueDecomposition class to the
> >> package? In that case, which algorithm is targeted to be used? Jacobi?
> >
> > We have not discussed this. Feel free to add to the wish list and
> > propose an algorithm. We also need to discuss how best to implement the
> > strategy pattern for decompositions in general, as there will often be
> > multiple algorithms to choose from.
>
> I have plugged in the EigenvalueDecomposition class from JAMA, which
> works fine for the PCA and CPCA modules. They do have a whole set of
> decompositions, and they might be easy to implement in the package (if
> they are free to be used).
Colt contains a port of much of JAMA, IIRC, and as Wolfgang posted not too long
ago, Colt's new license is much more compatible with the Apache license. I'm
not sure if it's sufficiently compatible for us to start merging in code,
though.
Al
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Matrix subMatrix and mean methods
Posted by Kim van der Linde <ki...@kimvdlinde.com>.
Phil Steitz wrote:
> I agree here as well. Do you see use cases where you will want to start
> with a double[][] array, perform matrix operations on it (say some
> decomposition) and then run stats on the resulting matrix? Will it be
> too onerous to make copies of the double[][] at each stage? If so, we
> need to think about access to the double[][].
I think keeping getData() will do the job. I generally do not like to
store the result of a calculation in the original matrix, it always
confuses me. If the content is of a different type, the name should be
different.
>> Is there the intention to add an EigenvalueDecomposition class to the
>> package? In that case, which algorithm is targeted to be used? Jacobi?
>
> We have not discussed this. Feel free to add to the wish list and
> propose an algorithm. We also need to discuss how best to implement the
> strategy pattern for decompositions in general, as there will often be
> multiple algorithms to choose from.
I have plugged in the EigenvalueDecomposition class from JAMA, which
works fine for the PCA and CPCA modules. They do have a whole set of
decompositions, and they might be easy to implement in the package (if
they are free to be used).
Kim
--
http://www.kimvdlinde.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Matrix subMatrix and mean methods
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Now that I'm back I'll try to catch up on this thread quickly
Phil Steitz wrote:
> Kim van der Linde wrote:
>
>> Hi Phil,
>>
>> I have been thinking for a few days on the Matrix classes.
>>
>> I think the Matrix class itself should contain all those methods that
>> do matrix calculations (add, subtract, multiply) that either a Matrix
>> themselfs or proporties of the Matrix (isSingular for example).
>
>
> I agree.
I have a slightly differing opinion of this, I do think we should have
specific methods for these tasks, but that they delegate to "Helpers"
that act to organize the code and allow for various forms of subclassing
and OO design principles.
for instance
public interface MatrixFunction{
public RealMatrix execute(double[][] a, double[][] b);
}
public RealMatrix add(RealMatrix m){
MatrixFunction addFunct = new MatrixFunction(){
public RealMatrix execute(double[][] a, double[][] b){
validateMatricies(a,b);
int rowCount = a.length;
int columnCount = a[0].length;
double[][] outData = new double[rowCount][columnCount];
for (int row = 0; row < rowCount; row++) {
for (int col = 0; col < columnCount; col++) {
outData[row][col] = data[row][col] + m.data[row][col];
}
}
return new RealMatrixImpl(outData);
}
};
return addFunct.execute(data, m.data);
}
what this allows us to do is provide customization of such processing in
the following sort of example;
public Matrix apply(MatrixFunction funct){
return funct.execute(double[][] a, double[][] b);
}
This allows us to expose certain capabilities to the advanced user while
keeping the encapsulation under control for the common user. The Common
user is less likely to make mistakes in handling the object, we can
separate the ideas of building customizations and properly handling
internal objects from that of the user who just wants to add two matrices.
>
> The mean
>
>> methods (getRowMeans) etc are statistics done ON a matrix, and I think
>> they should be in a seperate class, maybe called MatrixStats. This
>> enables aso he option to add variances and SD's which are needed for
>> column mean resp mean-SD standardizations, to be used for example in
>> PCA calculations when a covariance resp. correlation matrix is used.
>
>
> I agree here as well. Do you see use cases where you will want to start
> with a double[][] array, perform matrix operations on it (say some
> decomposition) and then run stats on the resulting matrix? Will it be
> too onerous to make copies of the double[][] at each stage? If so, we
> need to think about access to the double[][].
>
I don't think a single static utility class will be able to maintain all
this content in a fashion that allows for reuse, its the same argument I
maintained for the Statistics API during its refactoring. You can have a
MatrixStats class that provides nice static access to these
capabilities, but I think that actual implementations should be in
separate classes so they can easily be reused, customized, extended etc.
>>
>> Is there the intention to add an EigenvalueDecomposition class to the
>> package? In that case, which algorithm is targeted to be used? Jacobi?
>
>
> We have not discussed this. Feel free to add to the wish list and
> propose an algorithm. We also need to discuss how best to implement the
> strategy pattern for decompositions in general, as there will often be
> multiple algorithms to choose from.
>
An example of the need for this sort of design pattern, especially in
Linear Algebra, there are many many customized strategies for doing
various tasks on matrices for Eigenvalue decomposition via numerical
methods, a well organized framework will give us a landscape upon which
to implement theses strategies. Otherwise, again you end up with large
Static Classes with no room for extensibility.
-Mark
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Matrix subMatrix and mean methods
Posted by Phil Steitz <ph...@steitz.com>.
Kim van der Linde wrote:
> Hi Phil,
>
> I have been thinking for a few days on the Matrix classes.
>
> I think the Matrix class itself should contain all those methods that do
> matrix calculations (add, subtract, multiply) that either a Matrix
> themselfs or proporties of the Matrix (isSingular for example).
I agree.
The mean
> methods (getRowMeans) etc are statistics done ON a matrix, and I think
> they should be in a seperate class, maybe called MatrixStats. This
> enables aso he option to add variances and SD's which are needed for
> column mean resp mean-SD standardizations, to be used for example in PCA
> calculations when a covariance resp. correlation matrix is used.
I agree here as well. Do you see use cases where you will want to start
with a double[][] array, perform matrix operations on it (say some
decomposition) and then run stats on the resulting matrix? Will it be too
onerous to make copies of the double[][] at each stage? If so, we need to
think about access to the double[][].
>
> Is there the intention to add an EigenvalueDecomposition class to the
> package? In that case, which algorithm is targeted to be used? Jacobi?
We have not discussed this. Feel free to add to the wish list and propose
an algorithm. We also need to discuss how best to implement the strategy
pattern for decompositions in general, as there will often be multiple
algorithms to choose from.
Phil
>
> Cheers,
>
> Kim
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org