In preparation for the post-2.0 discussions, I've created three issues on the
tracker to deal with the consolidation of F2J (aka JLAPACK), netlib-java and
matrix-toolkits-java.
http://issues.apache.org/jira/browse/MATH-269
http://issues.apache.org/jira/browse/MATH-270
http://issues.apache.org/
I discovered/remembered something that might make the inclusion of Java
source translated BLAS/LAPACK code troublesome. The F2J translator does a
two step process... it generates Java from the Fortran, but then has to do
some jiggery-pokery to the class file to handle GOTO statements. That means
a
-1 to a TLP at the current time.
I really agree that the current momentum may be a flash.
On Sat, May 23, 2009 at 6:28 AM, Jin Mingjian wrote:
> I like the idea about the "top level math project":) Is it possible or
> interesting to host a sub-project for DSL to commons-math?(such as an
> enhan
I like the idea about the "top level math project":) Is it possible or
interesting to host a sub-project for DSL to commons-math?(such as an
enhanced Object-supported matlab-compatible script)
2009/5/23 Edward J. Yoon
> Hmm. It's a really great idea.
>
> I think It could be a top level math pro
Hmm. It's a really great idea.
I think It could be a top level math project of apache.
On Fri, May 22, 2009 at 7:37 PM, Sam Halliday wrote:
>
> Edward, Hama looks fantastic! I fully agree, 'distributed' isn't agreeable
> with commons-math. However, there might be parts of it that are relevant to
Hama is a proposed distributed matrix implementation system that is based on
using map-reduce to implement basic matrix operations and uses hbase to
store matrices. Getting useful performance out of this substrate for dense
matrix operations is likely to be fairly challenging due to I/O costs. Fo
> Is Hama related to Hadoop ?
Yes, it is.
On Fri, May 22, 2009 at 8:05 PM, Luc Maisonobe wrote:
> Sam Halliday a écrit :
>> Edward, Hama looks fantastic! I fully agree, 'distributed' isn't agreeable
>> with commons-math. However, there might be parts of it that are relevant to
>> Hama.
>
> Is Ha
On 22/05/2009, Phil Steitz wrote:
> Luc Maisonobe wrote:
>
> > Ted Dunning a écrit :
> >
> >
> > > In favor or not, Serializable shouldn't in in widely used interfaces.
> > >
> > > As an example, a Lucene index is a reasonable implementation of a sparse
> > > matrix.
> > >
> > > Would you require
Sam Halliday a écrit :
> Edward, Hama looks fantastic! I fully agree, 'distributed' isn't agreeable
> with commons-math. However, there might be parts of it that are relevant to
> Hama.
Is Hama related to Hadoop ?
>
> We should absolutely ensure that the "ducks are aligned" between
> commons-mat
Edward, Hama looks fantastic! I fully agree, 'distributed' isn't agreeable
with commons-math. However, there might be parts of it that are relevant to
Hama.
We should absolutely ensure that the "ducks are aligned" between
commons-math and Hama. It would be win-win if Hama were able to use
commons
Luc Maisonobe wrote:
Ted Dunning a écrit :
In favor or not, Serializable shouldn't in in widely used interfaces.
As an example, a Lucene index is a reasonable implementation of a sparse
matrix.
Would you require that I have to figure out how to make it serializable just
because I declare it
Ted Dunning a écrit :
> In favor or not, Serializable shouldn't in in widely used interfaces.
>
> As an example, a Lucene index is a reasonable implementation of a sparse
> matrix.
>
> Would you require that I have to figure out how to make it serializable just
> because I declare it as a Matrix?
It's a shame you can't use the GNU Trove project, it would be a perfect
robust backend for primitive mapping.
Bill Barker wrote:
>
> I've just been playing Code-Monkey, so Phil and Luc can do more
> interesting
> stuff, and we can get the 2.0 version released ;). OpenIntToDoubleHashMap
> was
In favor or not, Serializable shouldn't in in widely used interfaces.
As an example, a Lucene index is a reasonable implementation of a sparse
matrix.
Would you require that I have to figure out how to make it serializable just
because I declare it as a Matrix?
Do you imagine that most developer
Time zones mean that I tend to come in late here :(. More answers inline.
- Original Message -
From: "Sam Halliday"
To:
Sent: Thursday, May 21, 2009 3:13 AM
Subject: Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
Bill, I've had a look at som
That's really cool.
BTW, Can I ask about the plan of data distribution strategies of your
'distributed' package in the future? IMO, it seems, it doesn't sit
well with 'common-math' project.
If if there is a developer who wants to implement 'distributed', pls
let us know, too. I'm working for the
hursday, May 21, 2009 3:08:27 PM
Subject: Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
-1 on declaring things Serializable, especially if this is done everywhere.
Unless there is extensive testing and careful implementation, it is very,
very misleading to advertise this capabilit
-1 on declaring things Serializable, especially if this is done everywhere.
Unless there is extensive testing and careful implementation, it is very,
very misleading to advertise this capability. In addition, there are a
number of formats which are reasonable candidates. Casting a particular
form
Oh and when something implements Serializable, the serial form must be
either documented in the Javadocs or the Javadocs must be quite clear and
say that the serial form might change in future releases. Either way, don't
forget serialVersionUID and to update it if the serial form ever changes.
Absolutely remove from the interfaces... but leave on implementations :-)
That way all future implementations aren't forced to be compatible to their
first release.
Hopefully we'll address transport of instances in 2.1 with Matrix Market IO,
which should also encourage more efficient compression.
Sam Halliday a écrit :
> Regarding the name of ArrayRealMatrix. Please don't forget to include the
> "2DRow" part to the name (indicating a 2D array which is Row ordered) to
> indicate the implementation type. Post 2.0 I'll convince you that a 1D Array
> approach is best as it will lead to more eff
Sam Halliday a écrit :
> Luc... couldn't agree more regarding Serializable. Adding the Serializable
> interface instantly means you not only have to be API compatible with future
> releases but also binary Serializable compatible. This is what stung MTJ...
> it means you can't swap internal details
Regarding the name of ArrayRealMatrix. Please don't forget to include the
"2DRow" part to the name (indicating a 2D array which is Row ordered) to
indicate the implementation type. Post 2.0 I'll convince you that a 1D Array
approach is best as it will lead to more efficient use of BLAS and therefo
On Thu, May 21, 2009 at 11:31 AM, Sam Halliday wrote:
>
> Luc... couldn't agree more regarding Serializable. Adding the Serializable
> interface instantly means you not only have to be API compatible with future
> releases but also binary Serializable compatible. This is what stung MTJ...
> it mea
Luc, it absolutely would help the compiler... but the point is that the
return types might not remain as they currently are in future releases. For
example, if you multiply a dense matrix and a diagonal matrix... does it
make sense to return a dense matrix? No. :-)
Incidentally, in MTJ we have a
Luc... couldn't agree more regarding Serializable. Adding the Serializable
interface instantly means you not only have to be API compatible with future
releases but also binary Serializable compatible. This is what stung MTJ...
it means you can't swap internal details of fields.
I strongly recomm
On 21/05/2009, Luc Maisonobe wrote:
> sebb a écrit :
>
> > On 21/05/2009, Luc Maisonobe wrote:
> >> Sam Halliday a écrit :
> >>
> >>> Bill, I've had a look at some of the recent changes... some comments,
> >> > including some new thoughts:-
> >> >
> >> > - changing the return type to be
sebb a écrit :
> On 21/05/2009, Luc Maisonobe wrote:
>> Sam Halliday a écrit :
>>
>>> Bill, I've had a look at some of the recent changes... some comments,
>> > including some new thoughts:-
>> >
>> > - changing the return type to be actual classes was only supposed to be
>> for
>> > copy() f
On 21/05/2009, Luc Maisonobe wrote:
> Sam Halliday a écrit :
>
> > Bill, I've had a look at some of the recent changes... some comments,
> > including some new thoughts:-
> >
> > - changing the return type to be actual classes was only supposed to be for
> > copy() for 2.0. Doing this on multi
Sam Halliday a écrit :
> Bill, I've had a look at some of the recent changes... some comments,
> including some new thoughts:-
>
> - changing the return type to be actual classes was only supposed to be for
> copy() for 2.0. Doing this on multiply, add, etc is a big mistake... there
> is no guaran
Bill, I've had a look at some of the recent changes... some comments,
including some new thoughts:-
- changing the return type to be actual classes was only supposed to be for
copy() for 2.0. Doing this on multiply, add, etc is a big mistake... there
is no guarantee that is the best thing to do a
- Original Message -
From: "Phil Steitz"
To: "Commons Developers List"
Sent: Wednesday, May 20, 2009 11:05 AM
Subject: Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
Sam Halliday wrote:
Bill, I strongly discourage adding these methods a
Sam Halliday wrote:
Bill, I strongly discourage adding these methods at this time. We will regret
it.
If you don't want to change (i.e. add new methods) to an interface, then the
sensible thing is to omit these interfaces for 2.0 and introduce them with
2.1.
+1. Unless we are either a) agree
The output of f2j is almost unusable for normal mortals. There will
definitely be a wrapper layer.
Also, there is more than a wrapper in MTJ. There are also higher order
algorithms that use the lower level linear algebra provided by f2j.
On Tue, May 19, 2009 at 2:59 AM, Jin Mingjian wrote:
>
Can I ask a question? how about MTJ vs pure F2J? (If I don't use the native
part of MTJ.)
Can I get more must-have things? is it necessary to introduce a wrapper
layer?
Best regards,
Jin
Bill, I strongly discourage adding these methods at this time. We will regret
it.
If you don't want to change (i.e. add new methods) to an interface, then the
sensible thing is to omit these interfaces for 2.0 and introduce them with
2.1.
Bill Barker wrote:
>
> What I actually went for is to a
- Original Message -
From: "Sam Halliday"
To:
Sent: Monday, May 18, 2009 4:29 AM
Subject: Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
Excellent :-)
I think the consensus is to keep the sparse interfaces empty for now...
don't want to lock
Excellent :-)
I think the consensus is to keep the sparse interfaces empty for now...
don't want to lock ourselves into anything without detailed discussion,
which there is no time for before 2.0.
Just drop a note into the Javadocs to the effect that methods may be added
in the next release. I c
Luc Maisonobe wrote:
Phil Steitz a écrit :
Luc Maisonobe wrote:
Sam Halliday a écrit :
I've had a quick look at the 2.0 API and the only changes I'd like to
request
are:-
- create interfaces RealSparse{Matrix, Vector} to indicate a sparse
storage
implementation. Can be empty
Phil Steitz a écrit :
> Luc Maisonobe wrote:
>> Sam Halliday a écrit :
>>
>>> I've had a quick look at the 2.0 API and the only changes I'd like to
>>> request
>>> are:-
>>>
>>> - create interfaces RealSparse{Matrix, Vector} to indicate a sparse
>>> storage
>>> implementation. Can be empty (for n
Luc Maisonobe wrote:
Sam Halliday a écrit :
I've had a quick look at the 2.0 API and the only changes I'd like to request
are:-
- create interfaces RealSparse{Matrix, Vector} to indicate a sparse storage
implementation. Can be empty (for now).
I suppose these interfaces would extend R
Sam Halliday wrote:
Luc Maisonobe wrote:
Perhaps having a single additional method getSparcity() or
getLoadRatio() returning the ratio of elements set to the total number
as a double would be useful ?
Perhaps... but the shape is probably more important than the sparsity score
(which
Luc Maisonobe wrote:
Bill Barker a écrit :
- Original Message - From: "Ted Dunning"
To: "Commons Developers List"
Sent: Saturday, May 16, 2009 1:01 PM
Subject: Re: [math] Re: commons-math, matrix-toolkits-java and
consolidation
+1 on this chang
Luc Maisonobe wrote:
Sam Halliday a écrit :
I don't want to hold up a 2.0 release... however it would be a shame to
release an API that would restrict further inclusion of MTJ/BLAS, especially
in the sparse API. Would it be possible to hold back the linear algebra
updates for now?
If you'd r
Bill Barker a écrit :
>
> - Original Message - From: "Ted Dunning"
> To: "Commons Developers List"
> Sent: Saturday, May 16, 2009 1:01 PM
> Subject: Re: [math] Re: commons-math, matrix-toolkits-java and
> consolidation
>
>
>> +1
- Original Message -
From: "Ted Dunning"
To: "Commons Developers List"
Sent: Saturday, May 16, 2009 1:01 PM
Subject: Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
+1 on this change. Grand names like SparseRealMatrix should be reserved
getScarcity is probably still useful.
getSparseShapeOrClassOrWhateverItShouldBeCalled would be very, very helpful.
On Sat, May 16, 2009 at 11:12 AM, Sam Halliday wrote:
> Luc Maisonobe wrote:
> >
> > Perhaps having a single additional method getSparcity() or
> > getLoadRatio() returning the rati
+1 on this change. Grand names like SparseRealMatrix should be reserved for
the interfaces.
On Sat, May 16, 2009 at 10:26 AM, Luc Maisonobe wrote:
>
> > - rename SparseReal{Matrix, Vector} to OpenMapRealSparse{Matrix, Vector}.
> > Implement above interfaces.
>
> I have no opinion on that. What d
Luc Maisonobe wrote:
>
> Perhaps having a single additional method getSparcity() or
> getLoadRatio() returning the ratio of elements set to the total number
> as a double would be useful ?
>
Perhaps... but the shape is probably more important than the sparsity score
(which doesn't necessarily
Sam Halliday a écrit :
>
> Luc Maisonobe wrote:
>>> - create interfaces RealSparse{Matrix, Vector} to indicate a sparse
>>> storage
>>> implementation. Can be empty (for now).
>> I suppose these interfaces would extend Real{Matrix, Vector} ?
>>
>
> Exactly. In future, it might be wise to use the
Luc Maisonobe wrote:
>
>> - create interfaces RealSparse{Matrix, Vector} to indicate a sparse
>> storage
>> implementation. Can be empty (for now).
>
> I suppose these interfaces would extend Real{Matrix, Vector} ?
>
Exactly. In future, it might be wise to use the "subclass return trick" here
Sam Halliday a écrit :
> I've had a quick look at the 2.0 API and the only changes I'd like to request
> are:-
>
> - create interfaces RealSparse{Matrix, Vector} to indicate a sparse storage
> implementation. Can be empty (for now).
I suppose these interfaces would extend Real{Matrix, Vector} ?
Sam Halliday a écrit :
> I don't want to hold up a 2.0 release... however it would be a shame to
> release an API that would restrict further inclusion of MTJ/BLAS, especially
> in the sparse API. Would it be possible to hold back the linear algebra
> updates for now?
>
> If you'd really like to g
Sam Halliday a écrit :
> I suspected as much: that makes JAMA and Colt both deceased. Does anyone know
> how to contact the JAMA authors and ask them to make this explicit in the
> webpage? Asking to direct users to commons-math would be wise.
This fact appears at least here in this message:
http:
I've had a quick look at the 2.0 API and the only changes I'd like to request
are:-
- create interfaces RealSparse{Matrix, Vector} to indicate a sparse storage
implementation. Can be empty (for now).
- rename SparseReal{Matrix, Vector} to OpenMapRealSparse{Matrix, Vector}.
Implement above interfa
I don't want to hold up a 2.0 release... however it would be a shame to
release an API that would restrict further inclusion of MTJ/BLAS, especially
in the sparse API. Would it be possible to hold back the linear algebra
updates for now?
If you'd really like to get 2.0 out as it stands, then can
I suspected as much: that makes JAMA and Colt both deceased. Does anyone know
how to contact the JAMA authors and ask them to make this explicit in the
webpage? Asking to direct users to commons-math would be wise.
I have attempted to contact the author/maintainer of Colt on many occasions,
but I
Sam Halliday a écrit :
> Just to let you know, I've contacted the author of this blog post... who has
> recently written a library called jblas. I've asked him if he wants to be
> involved with the initiative here, to consolidate efforts for Java Linear
> Algebra packages.
>
> Incidentally... this
Sam Halliday a écrit :
> Luc, if the Apache team are happy to include source generated by f2j (which
> is therefore BSD license) then there is no reason at all to have a
> dependency!
Fine.
>
> The generator code from netlib-java need not be distributed as part of the
> final commons-math binary
I think netlib-java might actually be using the CLAPACK version of LAPACK...
the biggest problem with C/Fortran is the array indexing is different for
double[][]. CLAPACK addresses this.
LAPACK is still heavily used in reference implementations of standard
algorithms, although admittedly not as *
Luc, if the Apache team are happy to include source generated by f2j (which
is therefore BSD license) then there is no reason at all to have a
dependency!
The generator code from netlib-java need not be distributed as part of the
final commons-math binary, it is only needed to generate the .c fil
Luc Maisonobe wrote:
Phil Steitz a écrit :
Ted Dunning wrote:
Phil, I think we have much of the same desires and motivations, but we
seem
to come to somewhat, but not entirely different conclusions.
Assuming that (1) can be dealt with and assuming that (3) is already
dealt
with, do you
Sam Halliday a écrit :
> I've somehow missed much of this discussion, which has got a little confused.
> I'll repeat some key facts here:-
>
> - MTJ depends on netlib-java
> - I'm the maintainer of netlib-java
> - netlib-java depends on PURE JAVA code, generated by F2J from netlib.org
> BLAS/LAPAC
Just to let you know, I've contacted the author of this blog post... who has
recently written a library called jblas. I've asked him if he wants to be
involved with the initiative here, to consolidate efforts for Java Linear
Algebra packages.
Incidentally... this blog post references a very perva
I've somehow missed much of this discussion, which has got a little confused.
I'll repeat some key facts here:-
- MTJ depends on netlib-java
- I'm the maintainer of netlib-java
- netlib-java depends on PURE JAVA code, generated by F2J from netlib.org
BLAS/LAPACK (and ARPACK). Keith Seymour (autho
Ted, thanks for pointing this out... I'd never seen it before. Glad MTJ did
so well and I note that this isn't even with the optional native BLAS/LAPACK
:-)
Ted Dunning wrote:
>
> http://blog.mikiobraun.de/2009/04/some-benchmark-numbers-for-jblas.html
>
--
View this message in context:
http
Luc Maisonobe wrote:
>
> Ted Dunning a écrit :
>> As a start, I'd like to discourage the use of a solid implementation for
>>> SparseReal{Vector, Matrix}... please prefer an interface approach,
>>> allowing
>>> implementations based on the Templates project:-
>
> Maybe SparseRealMatrix was a b
I've asked Bjorn about an Apache license for MTJ and his reply was
"Yes, I don't see why not. The more users/developers, the better."
Ted Dunning wrote:
>
> On Thu, May 14, 2009 at 1:54 PM, Sam Halliday wrote:
>> I personally have no problems with my MTJ contributions being released
>> Apach
Phil Steitz a écrit :
> Ted Dunning wrote:
>> Phil, I think we have much of the same desires and motivations, but we
>> seem
>> to come to somewhat, but not entirely different conclusions.
>>
>> Assuming that (1) can be dealt with and assuming that (3) is already
>> dealt
>> with, do you still mind
Ted Dunning wrote:
Phil, I think we have much of the same desires and motivations, but we seem
to come to somewhat, but not entirely different conclusions.
Assuming that (1) can be dealt with and assuming that (3) is already dealt
with, do you still mind the inclusion of *optional*, automaticall
Phil, I think we have much of the same desires and motivations, but we seem
to come to somewhat, but not entirely different conclusions.
Assuming that (1) can be dealt with and assuming that (3) is already dealt
with, do you still mind the inclusion of *optional*, automatically generated
native co
Luc Maisonobe wrote:
Ted Dunning a écrit :
On Thu, May 14, 2009 at 3:18 AM, Sam Halliday wrote:
I am a maintainer of the matrix-toolkits-java
Which is an impressive piece of work, especially the transparent but
non-binding interface to the Atlas and Blas native packages. My co
On Thu, May 14, 2009 at 1:54 PM, Sam Halliday wrote:
> I personally have no problems with my MTJ contributions being released
> Apache. Bjorn-Ove is the person to talk to about the bulk of MTJ. I'll ask
> him!
>
Great.
MTJ depends on netlib-java, which is technically a translation of the
> origi
Replies inline:
Ted Dunning wrote:
>
>> As a start, I'd like to discourage the use of a solid implementation for
>> SparseReal{Vector, Matrix}... please prefer an interface approach,
>> allowing
>> implementations based on the Templates project:-
>
> Can you say more about what aspects of the
Ted Dunning a écrit :
> Dang.
>
> That is fast.
>
> What size matrices was this for?
>
> On Thu, May 14, 2009 at 12:09 PM, Luc Maisonobe wrote:
>
>> Some benchmarks I did a few weeks ago showed the new [math] linear
>> package implementation was quite fast and compared very well with native
>>
Dang.
That is fast.
What size matrices was this for?
On Thu, May 14, 2009 at 12:09 PM, Luc Maisonobe wrote:
> Some benchmarks I did a few weeks ago showed the new [math] linear
> package implementation was quite fast and compared very well with native
> fortran libraries for QR decomposition wi
Ted Dunning a écrit :
> On Thu, May 14, 2009 at 3:18 AM, Sam Halliday wrote:
>
>> I am a maintainer of the matrix-toolkits-java
>
>
> Which is an impressive piece of work, especially the transparent but
> non-binding interface to the Atlas and Blas native packages. My compliments
> to Bjørn-Ove
On Thu, May 14, 2009 at 3:18 AM, Sam Halliday wrote:
>
> I am a maintainer of the matrix-toolkits-java
Which is an impressive piece of work, especially the transparent but
non-binding interface to the Atlas and Blas native packages. My compliments
to Bjørn-Ove and all who have followed up on hi
Dear all,
I am a maintainer of the matrix-toolkits-java
http://code.google.com/p/matrix-toolkits-java/
which is a comprehensive collection of matrix data structures, linear
solvers, least squares methods, eigenvalue and singular value
decompositions.
This note is in regard to the commons-mat
79 matches
Mail list logo
