On Sat, May 16, 2009 at 11:47 PM, Robert Burrell Donkin
wrote:
> Henri Yandell wrote:
>> Go for it.
>>
>> Dave's an Apache committer nowadays, so get it going in the Sandbox,
>> give Dave some access and away you go :)
>
> +1
>
>> On Sat, May 16, 2009 at 5:32 PM, Dave Meikle wrote:
>>> Hi Robert,
Henri Yandell wrote:
> Go for it.
>
> Dave's an Apache committer nowadays, so get it going in the Sandbox,
> give Dave some access and away you go :)
+1
> On Sat, May 16, 2009 at 5:32 PM, Dave Meikle wrote:
>> Hi Robert,
>>
>> 2009/5/16 Robert Burrell Donkin
>>
>>> opinions?
>>>
>> Not sure wh
Go for it.
Dave's an Apache committer nowadays, so get it going in the Sandbox,
give Dave some access and away you go :)
On Sat, May 16, 2009 at 5:32 PM, Dave Meikle wrote:
> Hi Robert,
>
> 2009/5/16 Robert Burrell Donkin
>
>> opinions?
>>
>
> Not sure what others opinions are on this but I hav
Hi Robert,
2009/5/16 Robert Burrell Donkin
> opinions?
>
Not sure what others opinions are on this but I have projects that use the
component and have been keeping them in check myself, so would be interested
in this (see below).
>
> anyone else interested?
I had previously maven-ised this
- 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
for
the interfaces.
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
--- On Sat, 5/16/09, Phil Steitz wrote:
> From: Phil Steitz
> Subject: Re: New Sandbox Component Proposal: Commons JSON
> To: "Commons Developers List"
> Date: Saturday, May 16, 2009, 7:24 AM
> Henri Yandell wrote:
> > On Fri, May 15, 2009 at 6:44 PM, Phil Steitz
> wrote:
> >
> >> Christ
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
Henri Yandell wrote:
On Fri, May 15, 2009 at 6:44 PM, Phil Steitz wrote:
Christian Grobmeier wrote:
Dear Commons-Folks,
Yonik Seeley and I propose the creation of a new Sandbox component
within Apache Commons. We would like to name it Commons JSON since it
should deal with everything
i have a patch that uses commons-resources for i18n downstream in james
but the component has never had a release and is now inactive. this is a
bit of a shame since (in my experience) it is reasonably widely used.
some work would be needed to prepare it for a release. the build would
need upgradi
I put a 3.0-SNAPSHOT site up at
http://people.apache.org/~bayard/commons-lang/3.0-SNAPSHOT/
Let's you see the current backwards compat changes:
http://people.apache.org/~bayard/commons-lang/3.0-SNAPSHOT/clirr-report.html
Current Javadoc (beware of package.htmls that aren't updated yet):
htt
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
32 matches
Mail list logo
