commons-math, matrix-toolkits-java and consolidation

classic Classic list List threaded Threaded
93 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: [math] Re: commons-math, matrix-toolkits-java and consolidation

Luc Maisonobe
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, it is only needed to generate the .c files which
> allow for a native library at runtime. I would foresee the .c files being
> distributed as part of the commons-math binary download, with instructions
> on how to build the optional native library. The entire mechanism for doing
> this is entirely up for debate and review. The important thing is that there
> be a standardised BLAS/LAPACK API available.

Yes.

However, as both Phil and I have said, we still want to have 2.0 out
very soon. Adding a complete BLAS API is a huge task so I really prefer
to wait after 2.0. We can discuss about it here, of course. You could
also open a JIRA issue for requesting the enhancement, targeting 2.1.

Thanks
Luc

>
>
> 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 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 (author of f2j) deserves all the
>>> praise for that magnificent task! The necessary jar is distributed with
>>> netlib-java.
>>> - BLAS/LAPACK are industry standard APIs.
>>> - netlib-java is technically a "translation" of netlib.org's
>>> BLAS/LAPACK/ARPACK API, so is therefore BSD licensed
>>> - netlib-java can be *optionally* configured at runtime to use a native
>>> library instead of the Java implementation.
>>> - the java implementation is pretty damn fast and will be more than
>>> adequate
>>> for most users. However, it will *never* be as fast as native code
>>> running
>>> on specialist hardware (no matter how much the JVM improves).
>>>
>>> Being the maintainer of netlib-java, I'd be more than happy to re-license
>>> all the bits that aren't technically "translations" of netlib.org, for
>>> inclusion in commons-math (in fact, it makes sense to do so). But you'd
>>> still need to depend on the f2j translated implementation. They are BSD
>>> license.
>> This is becoming more and more interesting. However, do yo think it
>> would be possible to "include" the source (either manually written or
>> automatically translated) into [math] ? This would allow a
>> self-contained package.
>>
>> We already provide some code which technically comes from translated
>> netlib routines, for example part of the Levenberg-Marquardt or almost
>> everything in the singular value decomposition. The Netlib license
>> allows that and we have set up the appropriate notices (see the javadoc
>> and the NOTICE.txt file).
>>
>>> Hell, it makes a *lot* of sense for commons-math to provide the
>>> BLAS/LAPACK
>>> API... they are industry standards after all, and all reference
>>> implementations for linear algebra algorithms make use of them.
>> I strongly approve that for BLAS. I dream of the BLAS API being
>> mandatory in JVM implementations, but this will probably never happen.
>> Considering LAPACK, I am less convinced because the API is strongly
>> fortran-oriented, not using some of the object-oriented features that
>> are well suited for mathematical concepts. The algorithms and their
>> implementations are very good, and we already use them inside, but with
>> a different API.
>>
>> Luc
>>
>>>
>>> Luc Maisonobe wrote:
>>>> I have an additional reason for avoiding native libraries. Pure Java can
>>>> be processed by external tools for either inspection (think findbugs,
>>>> cobertura, traceability, auditing) or modification (think Nabla!). The
>>>> Nabla case is especially important to me, but I am aware this is a
>>>> corner-case.
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Re: commons-math, matrix-toolkits-java and consolidation

Luc Maisonobe
In reply to this post by Samuel Halliday
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 blog post references a very pervasive, yet abandoned,
> project named Colt. Colt was a brilliant library in its day (now numerically
> challenged), although riddled with license issues (depending on
> non-commercial and ill-defined not-for-military-use middleware). Colt is a
> reminder of what can happen when a great library is written but not
> maintained. There might be lessons to learn from their API... I know some
> projects that use it.
>
> It might be worthwhile contacting other Java Linear Algebra package authors,
> such as JAMA. JAMA is a very small library in comparison (no additional
> functionality over MTJ or commons-math)... but they might have a different
> take on APIs than we would have.

JAMA is a deceased project. We have based our API for decomposition
algorithms on the JAMA API, with some extensions we thought were useful
(see the class javadoc for the various decomposition interfaces). For
example, we have added interfaces instead of using only classes and we
have added solvers that could avoid building some large intermediate
matrices, thus greatly improving speed.

We have compared our results to JAMA. Here are some results I just rerun
for this message, with dimensions between 600 and 1000. Once again,
beware of the single case, single hardware, single trial effect: the
bench is most probably biased due to these characteristics.

multiplication: about 1.5 times faster with DenseRealMatrix
QR decomposition + solve: about 10 times faster at dimension 600, about
20-25 times faster at dimension 1000
eigen decomposition: about 3 times faster at dimension 600, about 6
times faster at dimension 1000

These results could have been expected: JAMA focused on the API, not on
the implementation and almost naive implementations have been used with
no consideration to the memory handling. So clearly, JAMA is superseded
on both the API, maintenance and efficiency aspects.


See for example these messages:
  http://markmail.org/message/a4d454alexugur2m
  http://markmail.org/message/h2rmq6wo7nwqzx4w
  http://markmail.org/message/l4cvopambgumrwbs

Luc

>
>
> Ted Dunning wrote:
>> http://blog.mikiobraun.de/2009/04/some-benchmark-numbers-for-jblas.html
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Re: commons-math, matrix-toolkits-java and consolidation

Samuel Halliday
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 keep getting bounced mail. It would be good to be able to warn people away from using these dead projects. Do you know of any others?

Luc Maisonobe wrote
JAMA is a deceased project.
Reply | Threaded
Open this post in threaded view
|

Re: [math] Re: commons-math, matrix-toolkits-java and consolidation

Samuel Halliday
In reply to this post by Luc Maisonobe
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 be involved in an API review to minimise any future problems? This might involve some API changes from today's snapshot (although, no extra features or anything heavy like that).

I agree... this is far too big a task for 2.0!

Luc Maisonobe wrote
However, as both Phil and I have said, we still want to have 2.0 out
very soon. Adding a complete BLAS API is a huge task so I really prefer
to wait after 2.0. We can discuss about it here, of course. You could
also open a JIRA issue for requesting the enhancement, targeting 2.1.
Reply | Threaded
Open this post in threaded view
|

Re: [math] Re: commons-math, matrix-toolkits-java and consolidation

Samuel Halliday
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 interfaces.
- implementations should subclass the return type of some methods in the Real{Matrix, Vector} API. e.g. RealVectorImpl.copy() returns a RealVector, but could declare that it returns a RealVectorImpl. This will avoid needless user casts. In future APIs, this could be a powerful way to define the return type of matrix-matrix computation when the storage classes are known... e.g. declaring that you return a DiagonalMatrix.
- is it too late to define a Norm enum and take that as a parameter, rather than explicit methods for each Norm type?

Other than that, looks good and I can'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 API changes from today's snapshot (although, no extra features or anything heavy like that).
Reply | Threaded
Open this post in threaded view
|

Re: [math] Re: commons-math, matrix-toolkits-java and consolidation

Luc Maisonobe
In reply to this post by Samuel Halliday
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://cio.nist.gov/esd/emaildir/lists/jama/msg01384.html

Note that the project cited in this message also already uses
commons-math and other mathematical libraries too.

>
> I have attempted to contact the author/maintainer of Colt on many occasions,
> but I keep getting bounced mail. It would be good to be able to warn people
> away from using these dead projects. Do you know of any others?

At least mantissa is in the same situation, but the link with
commons-math is already in the small FAQ.

I would personally not try to urge people to switch to our library. They
may well be happy with the status of these projects and switching has a
time cost for adaptation to new API and validation.

>
>
> Luc Maisonobe wrote:
>> JAMA is a deceased project.
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Re: commons-math, matrix-toolkits-java and consolidation

Luc Maisonobe
In reply to this post by Samuel Halliday
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 get 2.0 out as it stands, then can I be involved in
> an API review to minimise any future problems? This might involve some API
> changes from today's snapshot (although, no extra features or anything heavy
> like that).

Of course you can look at the API and comment on it or suggest changes.
If they are wise and can be implemented quickly, we'll probably do it.
If you want some changes to be included, your best bet is to explain
them on the list and to provide patches for that using JIRA.

>
> I agree... this is far too big a task for 2.0!
>
>
> Luc Maisonobe wrote:
>> However, as both Phil and I have said, we still want to have 2.0 out
>> very soon. Adding a complete BLAS API is a huge task so I really prefer
>> to wait after 2.0. We can discuss about it here, of course. You could
>> also open a JIRA issue for requesting the enhancement, targeting 2.1.
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Re: commons-math, matrix-toolkits-java and consolidation

Luc Maisonobe
In reply to this post by Samuel Halliday
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} ?

> - rename SparseReal{Matrix, Vector} to OpenMapRealSparse{Matrix, Vector}.
> Implement above interfaces.

I have no opinion on that. What do others think ?

> - implementations should subclass the return type of some methods in the
> Real{Matrix, Vector} API. e.g. RealVectorImpl.copy() returns a RealVector,
> but could declare that it returns a RealVectorImpl. This will avoid needless
> user casts. In future APIs, this could be a powerful way to define the
> return type of matrix-matrix computation when the storage classes are
> known... e.g. declaring that you return a DiagonalMatrix.

I didn't know changing the return type to a subtype was allowed when
implementing an interface! This is for sure a good thing to do and could
probably be used in many other places too.

> - is it too late to define a Norm enum and take that as a parameter, rather
> than explicit methods for each Norm type?

There are many places where we use the same pattern outside of linear
algebra. I'm reluctant to change this because if we extend the enum
later, we may forget to add a new case in all implementations (somewhere
in a switch statement), so we should add an exception for defensive
programming. A method name enforced in an interface prevent such errors,
you cannot compile your implementation if you forget a method.

>
> Other than that, looks good and I can'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.

Fine.

Luc

>
>
> Sam Halliday wrote:
>> can I be involved in an API review to minimise any future problems? This
>> might involve some API changes from today's snapshot (although, no extra
>> features or anything heavy like that).
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Re: commons-math, matrix-toolkits-java and consolidation

Samuel Halliday
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 too, but leaving it blank for now gives the best options for future releases.

Luc Maisonobe wrote
I didn't know changing the return type to a subtype was allowed when
implementing an interface! This is for sure a good thing to do and could
probably be used in many other places too.
Cool, eh? :-) In Joshua Bloch's book, he recommends being as general as possible in the parameters and as specific as possible in the return type. The only problem with being specific in the return type is that you are stuck with it. For that reason, it's probably best not to do this everywhere just yet. It's one of those little API details that can be open for change in the future whilst also being fully backwards compatible ;-)

Luc Maisonobe wrote
> - is it too late to define a Norm enum and take that as a parameter, rather
> than explicit methods for each Norm type?

There are many places where we use the same pattern outside of linear
algebra. I'm reluctant to change this because if we extend the enum
later...
OK, that makes sense.

One of the first tasks for MTJ integration can be the inclusion of the many sparse storage types (and associated numerical optimisations). That's why I'm keen to have the current sparse implementation be specific about its "shape" in its name. Otherwise it'll be the odd one out ;-)
Reply | Threaded
Open this post in threaded view
|

Re: [math] Re: commons-math, matrix-toolkits-java and consolidation

Luc Maisonobe
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 "subclass return trick" here
> too, but leaving it blank for now gives the best options for future
> releases.

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 ?

>
>
> Luc Maisonobe wrote:
>> I didn't know changing the return type to a subtype was allowed when
>> implementing an interface! This is for sure a good thing to do and could
>> probably be used in many other places too.
>>
>
> Cool, eh? :-) In Joshua Bloch's book, he recommends being as general as
> possible in the parameters and as specific as possible in the return type.
> The only problem with being specific in the return type is that you are
> stuck with it. For that reason, it's probably best not to do this everywhere
> just yet. It's one of those little API details that can be open for change
> in the future whilst also being fully backwards compatible ;-)
>
>
> Luc Maisonobe wrote:
>>> - is it too late to define a Norm enum and take that as a parameter,
>>> rather
>>> than explicit methods for each Norm type?
>> There are many places where we use the same pattern outside of linear
>> algebra. I'm reluctant to change this because if we extend the enum
>> later...
>>
>
> OK, that makes sense.
>
> One of the first tasks for MTJ integration can be the inclusion of the many
> sparse storage types (and associated numerical optimisations). That's why
> I'm keen to have the current sparse implementation be specific about its
> "shape" in its name. Otherwise it'll be the odd one out ;-)
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Re: commons-math, matrix-toolkits-java and consolidation

Samuel Halliday
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 mean anything, and might actually be difficult to calculate for some implementations). I recommend leaving it empty for now and we can discuss it in much more detail for 2.1 :-)
Reply | Threaded
Open this post in threaded view
|

Re: [math] Re: commons-math, matrix-toolkits-java and consolidation

Ted Dunning
In reply to this post by Luc Maisonobe
+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 <[hidden email]>wrote:

>
> > - rename SparseReal{Matrix, Vector} to OpenMapRealSparse{Matrix, Vector}.
> > Implement above interfaces.
>
> I have no opinion on that. What do others think ?




--
Ted Dunning, CTO
DeepDyve
Reply | Threaded
Open this post in threaded view
|

Re: [math] Re: commons-math, matrix-toolkits-java and consolidation

Ted Dunning
In reply to this post by Samuel Halliday
getScarcity is probably still useful.

getSparseShapeOrClassOrWhateverItShouldBeCalled would be very, very helpful.

On Sat, May 16, 2009 at 11:12 AM, Sam Halliday <[hidden email]>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 doesn't necessarily mean anything, and might actually be difficult
> to
> calculate for some implementations). I recommend leaving it empty for now
> and we can discuss it in much more detail for 2.1 :-)




--
Ted Dunning, CTO
DeepDyve
Reply | Threaded
Open this post in threaded view
|

Re: [math] Re: commons-math, matrix-toolkits-java and consolidation

Bill Barker
In reply to this post by Ted Dunning

----- Original Message -----
From: "Ted Dunning" <[hidden email]>
To: "Commons Developers List" <[hidden email]>
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.
>

I'm +1 on these grounds (and, yes, that means I'm volunteering to do the
work).  I could add the getSparcity method as well (the only one that is
useful for 2.0).  Could do the getShape which would presumably return an
enum (which would only have one element in 2.0) to ease the pain of
upgrading to 2.1 when there are more.



> On Sat, May 16, 2009 at 10:26 AM, Luc Maisonobe
> <[hidden email]>wrote:
>
>>
>> > - rename SparseReal{Matrix, Vector} to OpenMapRealSparse{Matrix,
>> > Vector}.
>> > Implement above interfaces.
>>
>> I have no opinion on that. What do others think ?
>
>
>
>
> --
> Ted Dunning, CTO
> DeepDyve
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Re: commons-math, matrix-toolkits-java and consolidation

Luc Maisonobe
Bill Barker a écrit :

>
> ----- Original Message ----- From: "Ted Dunning" <[hidden email]>
> To: "Commons Developers List" <[hidden email]>
> 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.
>>
>
> I'm +1 on these grounds (and, yes, that means I'm volunteering to do the
> work).  I could add the getSparcity method as well (the only one that is
> useful for 2.0).  Could do the getShape which would presumably return an
> enum (which would only have one element in 2.0) to ease the pain of
> upgrading to 2.1 when there are more.

Sounds good, I'll let you handle this and focus on my very late stiff
ODE handling. Anyone volunteering for the return values of multiply, add
and similar methods on RealMatrixImpl, DenseRealMatrix, ... ?

Thanks,
Luc

>
>
>
>> On Sat, May 16, 2009 at 10:26 AM, Luc Maisonobe
>> <[hidden email]>wrote:
>>
>>>
>>> > - rename SparseReal{Matrix, Vector} to OpenMapRealSparse{Matrix, >
>>> Vector}.
>>> > Implement above interfaces.
>>>
>>> I have no opinion on that. What do others think ?
>>
>>
>>
>>
>> --
>> Ted Dunning, CTO
>> DeepDyve
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Re: commons-math, matrix-toolkits-java and consolidation

Phil Steitz
In reply to this post by Luc Maisonobe
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 really like to get 2.0 out as it stands, then can I be involved in
>> an API review to minimise any future problems? This might involve some API
>> changes from today's snapshot (although, no extra features or anything heavy
>> like that).
>>    
>
> Of course you can look at the API and comment on it or suggest changes.
> If they are wise and can be implemented quickly, we'll probably do it.
> If you want some changes to be included, your best bet is to explain
> them on the list and to provide patches for that using JIRA.
>  
++1 - by all means, now is the time to comment on / suggest changes to
the 2.0 API.

Phil

>  
>> I agree... this is far too big a task for 2.0!
>>
>>
>> Luc Maisonobe wrote:
>>    
>>> However, as both Phil and I have said, we still want to have 2.0 out
>>> very soon. Adding a complete BLAS API is a huge task so I really prefer
>>> to wait after 2.0. We can discuss about it here, of course. You could
>>> also open a JIRA issue for requesting the enhancement, targeting 2.1.
>>>
>>>      
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>  


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Re: commons-math, matrix-toolkits-java and consolidation

Phil Steitz
In reply to this post by Luc Maisonobe
Luc Maisonobe wrote:

> Bill Barker a écrit :
>  
>> ----- Original Message ----- From: "Ted Dunning" <[hidden email]>
>> To: "Commons Developers List" <[hidden email]>
>> 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.
>>>
>>>      
>> I'm +1 on these grounds (and, yes, that means I'm volunteering to do the
>> work).  I could add the getSparcity method as well (the only one that is
>> useful for 2.0).  Could do the getShape which would presumably return an
>> enum (which would only have one element in 2.0) to ease the pain of
>> upgrading to 2.1 when there are more.
>>    
>
> Sounds good, I'll let you handle this and focus on my very late stiff
> ODE handling. Anyone volunteering for the return values of multiply, add
> and similar methods on RealMatrixImpl, DenseRealMatrix, ... ?
>  
I am getting close to done on the stats stuff and will take a look if no
one else has picked this up by the time I get to it.  

Phil

> Thanks,
> Luc
>
>  
>>
>>    
>>> On Sat, May 16, 2009 at 10:26 AM, Luc Maisonobe
>>> <[hidden email]>wrote:
>>>
>>>      
>>>>> - rename SparseReal{Matrix, Vector} to OpenMapRealSparse{Matrix, >
>>>>>          
>>>> Vector}.
>>>>        
>>>>> Implement above interfaces.
>>>>>          
>>>> I have no opinion on that. What do others think ?
>>>>        
>>>
>>>
>>> --
>>> Ted Dunning, CTO
>>> DeepDyve
>>>
>>>      
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>    
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>  


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Re: commons-math, matrix-toolkits-java and consolidation

Phil Steitz
In reply to this post by Samuel Halliday
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 doesn't necessarily mean anything, and might actually be difficult to
> calculate for some implementations). I recommend leaving it empty for now
> and we can discuss it in much more detail for 2.1 :-)
>  
+1 for leaving leaving RealSparse{Matrix, Vector} as markers (empty).  
Defining a suitable shape property and exposing that is a good idea, but
will take some time and discussion.  Also, if getSparcity() is of
limited value and may be hard to compute for some impls, we need think
carefully about putting it into the base interface.  So leaving these as
markers seems reasonable.

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Re: commons-math, matrix-toolkits-java and consolidation

Phil Steitz
In reply to this post by Luc Maisonobe
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 Real{Matrix, Vector} ?
>
>  
>> - rename SparseReal{Matrix, Vector} to OpenMapRealSparse{Matrix, Vector}.
>> Implement above interfaces.
>>    
>
> I have no opinion on that. What do others think ?
>  
+1 for "dethroning" ;)

With the new interfaces, we could also drop the "Sparse" from the name -
i.e, "OpenMapRealMatrix"

I am wondering now whether similar marking and "dethroning" should
happen on the dense side - i.e DenseReal{Matrix, Vector},
BlockRealMatrix (currently DenseRealMatrix), ArrayRealMatrix (currently
RealMatrixImpl)?

>  
>> - implementations should subclass the return type of some methods in the
>> Real{Matrix, Vector} API. e.g. RealVectorImpl.copy() returns a RealVector,
>> but could declare that it returns a RealVectorImpl. This will avoid needless
>> user casts. In future APIs, this could be a powerful way to define the
>> return type of matrix-matrix computation when the storage classes are
>> known... e.g. declaring that you return a DiagonalMatrix.
>>    
>
> I didn't know changing the return type to a subtype was allowed when
> implementing an interface! This is for sure a good thing to do and could
> probably be used in many other places too.
>  
+1 in general, but need to realize that when implemented, this changes
locks us in.  In the specific cases mentioned above, this is a
no-brainer, but there are others (mostly in the decomp classes) where it
is not so obvious.

>  
>> - is it too late to define a Norm enum and take that as a parameter, rather
>> than explicit methods for each Norm type?
>>    
>
> There are many places where we use the same pattern outside of linear
> algebra. I'm reluctant to change this because if we extend the enum
> later, we may forget to add a new case in all implementations (somewhere
> in a switch statement), so we should add an exception for defensive
> programming. A method name enforced in an interface prevent such errors,
> you cannot compile your implementation if you forget a method.
>  
Agree with Luc on this, but more from a Java style than maintenance
standpoint.  We have tried in general to stay away from "behavior flags"
in method signatures up to now.

Phil
 

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Re: commons-math, matrix-toolkits-java and consolidation

Luc Maisonobe
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 now).
>>>    
>>
>> I suppose these interfaces would extend Real{Matrix, Vector} ?
>>
>>  
>>> - rename SparseReal{Matrix, Vector} to OpenMapRealSparse{Matrix,
>>> Vector}.
>>> Implement above interfaces.
>>>    
>>
>> I have no opinion on that. What do others think ?
>>  
> +1 for "dethroning" ;)
>
> With the new interfaces, we could also drop the "Sparse" from the name -
> i.e, "OpenMapRealMatrix"
>
> I am wondering now whether similar marking and "dethroning" should
> happen on the dense side - i.e DenseReal{Matrix, Vector},
> BlockRealMatrix (currently DenseRealMatrix), ArrayRealMatrix (currently
> RealMatrixImpl)?

+1. This is simple for DenseRealMatrix since it has been created after
1.2, but RealMatrixImpl may induce more problems to users. Should we
copy an deprecate ?

>>  
>>> - implementations should subclass the return type of some methods in the
>>> Real{Matrix, Vector} API. e.g. RealVectorImpl.copy() returns a
>>> RealVector,
>>> but could declare that it returns a RealVectorImpl. This will avoid
>>> needless
>>> user casts. In future APIs, this could be a powerful way to define the
>>> return type of matrix-matrix computation when the storage classes are
>>> known... e.g. declaring that you return a DiagonalMatrix.    
>>
>> I didn't know changing the return type to a subtype was allowed when
>> implementing an interface! This is for sure a good thing to do and could
>> probably be used in many other places too.
>>  
> +1 in general, but need to realize that when implemented, this changes
> locks us in.  In the specific cases mentioned above, this is a
> no-brainer, but there are others (mostly in the decomp classes) where it
> is not so obvious.
>
>>  
>>> - is it too late to define a Norm enum and take that as a parameter,
>>> rather
>>> than explicit methods for each Norm type?
>>>    
>>
>> There are many places where we use the same pattern outside of linear
>> algebra. I'm reluctant to change this because if we extend the enum
>> later, we may forget to add a new case in all implementations (somewhere
>> in a switch statement), so we should add an exception for defensive
>> programming. A method name enforced in an interface prevent such errors,
>> you cannot compile your implementation if you forget a method.
>>  
> Agree with Luc on this, but more from a Java style than maintenance
> standpoint.  We have tried in general to stay away from "behavior flags"
> in method signatures up to now.
>
> Phil
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12345