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
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
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
68 matches
Mail list logo
