commons-math linear.decomposition for 2.0

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

commons-math linear.decomposition for 2.0

Samuel Halliday
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 have implementations that are optimised for the storage types in the future.

Since the decompositions are in a separate package, that means the default implementations will never be able to access implementation details of the matrices they are working on. Unless future implementations end up going into the linear package. That will just get messy and users will be confused why some decompositions are in "linear" and others are in "decompositions".

I recommend that the decompositions package be simply merged into the linear package. This is the way we do it in matrix-toolkits-java and to the best of my knowledge, nobody has complained about that structure for any reason.
Reply | Threaded
Open this post in threaded view
|

Re: commons-math linear.decomposition for 2.0

Luc Maisonobe
Sam Halliday a écrit :

> 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 have
> implementations that are optimised for the storage types in the future.
>
> Since the decompositions are in a separate package, that means the default
> implementations will never be able to access implementation details of the
> matrices they are working on. Unless future implementations end up going
> into the linear package. That will just get messy and users will be confused
> why some decompositions are in "linear" and others are in "decompositions".
>
> I recommend that the decompositions package be simply merged into the linear
> package. This is the way we do it in matrix-toolkits-java and to the best of
> my knowledge, nobody has complained about that structure for any reason.
>

The decision was taken on 15th February:
http://markmail.org/thread/62peuye5psp6o433


I understand your concerns and agree with them. If everybody is OK, we
can go back to a single (but very large) linear package.

I won't start an official vote on this though ...

Luc

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

Reply | Threaded
Open this post in threaded view
|

Re: commons-math linear.decomposition for 2.0

Ted Dunning
In reply to this post by Samuel Halliday
I think that packages are nice and all, but commons.math is pretty
aggressive about balkanizing the name space.

+1 for merging.

On Fri, May 29, 2009 at 1:46 AM, Sam Halliday <[hidden email]>wrote:

> I recommend that the decompositions package be simply merged into the
> linear
> package.
>



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

[math] Re: commons-math linear.decomposition for 2.0

Luc Maisonobe
Ted Dunning a écrit :
> I think that packages are nice and all, but commons.math is pretty
> aggressive about balkanizing the name space.
>
> +1 for merging.

Since nobody voiced against the merging, I'm going to merge
decomposition back to the linear package as suggested by Sam, thus
reverting the choice made a few months ago.

Luc

>
> On Fri, May 29, 2009 at 1:46 AM, Sam Halliday <[hidden email]>wrote:
>
>> I recommend that the decompositions package be simply merged into the
>> linear
>> package.
>>
>
>
>


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