Dear all,
The decompositions in the linear package have been given their own
package... I'm just flagging up a concern (prior to the release of the API
for 2.0) that this might make things tricky in the future. The current
implementations of the decompositions are nice and general, but we will ha
e.org/jira/browse/MATH-271
Sam Halliday wrote:
>
> ...
> This note is in regard to the commons-math library. It is clear that our
> projects dovetail, especially when I look at "linear" in version 2.0 of
> the API. It would be good if we could either complement or cons
ith this if they have any
Maven experience!
Sam Halliday wrote:
>
> 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,
uture? 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 Hama
> (http://incubator.apache.org/hama) with ScaLAPACK members.
>
&g
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
anges.
Sam Halliday wrote:
>
> 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 Matr
ompression.
Luc Maisonobe wrote:
>
> 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
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
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
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
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
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:
>
> 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
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
't see any obvious conflicts that would
void an MTJ merge! Most of the changes will be internal anyway, depending
primarily on the path forward for BLAS/LAPACK use.
Sam Halliday wrote:
>
> can I be involved in an API review to minimise any future problems? This
> might involve some
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
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 *
that there
be a standardised BLAS/LAPACK API available.
Luc Maisonobe wrote:
>
> 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
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
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
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
27 matches
Mail list logo
