Hi Ted,
I think we might have a misunderstanding. What I am discussing is not the
general implementation for a matrix, but the base interface that would be
required for input into optimizers. I was saying that there should not be a
burden of implementing visitor pattern for users creating a
On 12/29/12 1:08 AM, Luc Maisonobe wrote:
Le 29/12/2012 04:09, Gilles Sadowski a écrit :
Hi.
Hi Gilles,
[...]
third is just bug-fix. Does the fix for the issue that started this
thread change the API? If so, we would need to cut 3.2 in any case.
The current fix does change the usage (one
Hi,
In my opinion is that the whole weights fiasco is consequence of
improper design, as much as anything else. All components should be
as simple as possible, with any additional add ons, like weights,
not added to the base implementation, but instead done as an extension
of these classes. If
Dim has it exactly right here.
On Sun, Dec 30, 2012 at 10:38 AM, Dimitri Pourbaix pourb...@astro.ulb.ac.be
wrote:
In optimization, the user supplies the function to be minimised. In curve
fitting, the user supplies a series of observations and the model to be
fitted. Trying to combine both
Konstantin,
We are close then. Yes optimization should use vector methods as possible.
But visitor functions are very easy to add in an abstract class. They
impose very little burden on the implementor.
On Sun, Dec 30, 2012 at 8:52 AM, Konstantin Berlin kber...@gmail.comwrote:
I think we
Hello,
Using the visitor pattern as a way to implement in-place basic linear
algebra operations was only a suggestion, I am not sure it's the best
option, even if I do think it's a simple and elegant option. However...
I think we might have a misunderstanding. What I am discussing is not the
The GPU requires native code that is executed on the GPU. Standard linear
algebra libraries exist for this so if the API can express a standard
linear algebra routine concisely, then the GPU can be used. General Java
code usually can't be executed on a GPU.
There is some late breaking news on
On Dec 30, 2012, at 2:26 PM, Sébastien Brisard sebastien.bris...@m4x.org
wrote:
Hello,
Using the visitor pattern as a way to implement in-place basic linear
algebra operations was only a suggestion, I am not sure it's the best
option, even if I do think it's a simple and elegant option.
On Sun, Dec 30, 2012 at 12:16 PM, Konstantin Berlin kber...@gmail.comwrote:
...
There would be no burden on the user's side: the visitor pattern has been
implemented for RealVectors in version 3.1. Besides, we could provide all
the relevant visitors (addition, scaling, …)
There is an
Hello.
[As Phil suggested, please stop extending this thread; and rather open new
ones on specific points in order to focus the discussion(s).]
Yes, abd I agree with that. However, I found the javadoc to be
ambiguous. It says The following data will be looked for: followed by
a list. There
Hi,
2012/12/29 Gilles Sadowski gil...@harfang.homelinux.org
Hi.
[...]
third is just bug-fix. Does the fix for the issue that started this
thread change the API? If so, we would need to cut 3.2 in any case.
The current fix does change the usage (one needs to call optimize with an
Le 29/12/2012 04:09, Gilles Sadowski a écrit :
Hi.
Hi Gilles,
[...]
third is just bug-fix. Does the fix for the issue that started this
thread change the API? If so, we would need to cut 3.2 in any case.
The current fix does change the usage (one needs to call optimize with an
Hello,
2012/12/28 Konstantin Berlin kber...@gmail.com
That's what I was going to write. At the moment, the current
implementation
for sparse matrices and vector is deprecated, for lack of convincing
fixes
for the bugs which have been found. These bugs are mainly related to the
fact
Gilles,
Handling weighted observations must take correlations into account, i.e. use
a _matrix_.
There is the _practical_ problem of memory. Solving it correctly is by
using a sparse implementation (and this is actually an implementation
_detail_).
The problem is where something becomes a
Le 29/12/2012 10:08, Luc Maisonobe a écrit :
Le 29/12/2012 04:09, Gilles Sadowski a écrit :
Hi.
Hi Gilles,
[...]
third is just bug-fix. Does the fix for the issue that started this
thread change the API? If so, we would need to cut 3.2 in any case.
The current fix does change the
On Sat, Dec 29, 2012 at 10:43:11AM +0100, Luc Maisonobe wrote:
Le 29/12/2012 10:08, Luc Maisonobe a écrit :
Le 29/12/2012 04:09, Gilles Sadowski a écrit :
Hi.
Hi Gilles,
[...]
third is just bug-fix. Does the fix for the issue that started this
thread change the API? If so,
Le 29/12/2012 12:34, Gilles Sadowski a écrit :
On Sat, Dec 29, 2012 at 10:43:11AM +0100, Luc Maisonobe wrote:
Le 29/12/2012 10:08, Luc Maisonobe a écrit :
Le 29/12/2012 04:09, Gilles Sadowski a écrit :
Hi.
Hi Gilles,
[...]
third is just bug-fix. Does the fix for the issue that started
On Sat, Dec 29, 2012 at 10:22:20AM +0100, Dimitri Pourbaix wrote:
Gilles,
Handling weighted observations must take correlations into account, i.e. use
a _matrix_.
There is the _practical_ problem of memory. Solving it correctly is by
using a sparse implementation (and this is actually an
Hi.
[...]
[1] The inconsistencies that led to the deprecation will have no bearing
on usage within the optimizers.
[2] The latter option seems likely to entail a fair amount of work to
improve the performance of OpenMapRealMatrix (which is quite poor
for some operations,
On 12/29/12 4:16 AM, Luc Maisonobe wrote:
Le 29/12/2012 12:34, Gilles Sadowski a écrit :
On Sat, Dec 29, 2012 at 10:43:11AM +0100, Luc Maisonobe wrote:
Le 29/12/2012 10:08, Luc Maisonobe a écrit :
Le 29/12/2012 04:09, Gilles Sadowski a écrit :
Hi.
Hi Gilles,
[...]
third is just bug-fix.
I think this issue can be overcome by proper OO design, and hacked on to
the current interface for now.
We can create an InPlace interface that all linear operators (including
RealMatrix etc) would implement. For example in a hypothetical
InPlaceMatrix class
function InPlaceVector
Actually, the visitor pattern or variants thereof can produce very
performant linear algebra implementations. You can't usually get quite
down to optimized BLAS performance, but you get pretty darned fast code.
The reason is that the visitor is typically a very simple class which is
immediately
That's a good point about the compiler. I never tested the performance of
visitors vs. sequential array access. I just don't want the vector operations
to be tied to any particular implementation detail.
On Dec 29, 2012, at 6:30 PM, Ted Dunning ted.dunn...@gmail.com wrote:
Actually, the
Hi,
In my opinion is that the whole weights fiasco is consequence of improper
design, as much as anything else. All components should be as simple as
possible, with any additional add ons, like weights, not added to the base
implementation, but instead done as an extension of these classes. If
Also. If you have GPU implementation of a matrix, or use another type of a
vector processor, there is no way you can program that in if you force vector
operations to use a visitor patterns.
On Dec 29, 2012, at 6:43 PM, Konstantin Berlin kber...@gmail.com wrote:
That's a good point about the
Who said force? Linear algebra operations should be available.
Visitors should be available.
Your mileage will vary. That was always true.
On Sat, Dec 29, 2012 at 3:59 PM, Konstantin Berlin kber...@gmail.comwrote:
Also. If you have GPU implementation of a matrix, or use another type of a
Hi all,
I have encountered a major problem with version 3.1 just released.
This problem occurs in the revamped optimizers. One of the
OptimizationData implementations we can pass to multivariate vector
optimizers is the weight of the various observations.
In all cases I can think of, this weight
Hi,
I am not clear on the use of weights in a non-least squares problem is. In a
least-squares problem the weights can simply be taken in by the user in their
input function. So the weights option is a convenience feature, any
non-standard matrix weights could be programmed in by the user, if
Luc,
However, it is also possible to set a non-diagonal weight matrix, and
one class (AbstractLeastSquaresOptimizer) performs an eigen dcomposition
on the matrix to extract its square root. I don't know any use case for
this, but it has been set up this way, so I guess someone has a use for
On 12/28/12 7:08 AM, Dimitri Pourbaix wrote:
Luc,
However, it is also possible to set a non-diagonal weight matrix,
and
one class (AbstractLeastSquaresOptimizer) performs an eigen
dcomposition
on the matrix to extract its square root. I don't know any use
case for
this, but it has been
Le 28/12/2012 16:08, Dimitri Pourbaix a écrit :
Luc,
However, it is also possible to set a non-diagonal weight matrix, and
one class (AbstractLeastSquaresOptimizer) performs an eigen dcomposition
on the matrix to extract its square root. I don't know any use case for
this, but it has been
Luc,
So in order to make sure I understand your point, you would be OK if I
deprecate the non-diagonal weights, in which case users needing this
would have to implement it themselves by premultiplication (as both you
and Konstantin seem to propose)?
Yes, exactly.
Sure, but for the record
On 12/28/12 8:12 AM, Dimitri Pourbaix wrote:
Luc,
So in order to make sure I understand your point, you would be OK
if I
deprecate the non-diagonal weights, in which case users needing this
would have to implement it themselves by premultiplication (as
both you
and Konstantin seem to
Hi,
I can understand Dimitri's frustration, it seems the optimization framework
gets worse with every iteration. However, we should probably look forward and
think about how to design it properly instead.
Several times I brought out some problems and ideas about the package and it
seems the
On 12/28/12 8:51 AM, Konstantin Berlin wrote:
Hi,
I can understand Dimitri's frustration, it seems the optimization framework
gets worse with every iteration. However, we should probably look forward and
think about how to design it properly instead.
+1 - though we have the constraint
Several times I brought out some problems and ideas about the package and it
seems the only person who has an opinion is Gilles.
I will list what I consider to be major problems
1) The OO design is bad, too much inheritance which could be handled better
by interfaces,
We may have gone
Hi,
I can understand Dimitri's frustration, it seems the optimization
framework gets worse with every iteration. However, we should probably
look forward and think about how to design it properly instead.
+1 - though we have the constraint that we need to maintain backward
compatibility until
Le 28/12/2012 17:51, Konstantin Berlin a écrit :
Hi,
I can understand Dimitri's frustration, it seems the optimization
framework gets worse with every iteration. However, we should
probably look forward and think about how to design it properly
instead.
Several times I brought out some
On 12/28/12 9:58 AM, Luc Maisonobe wrote:
Le 28/12/2012 17:51, Konstantin Berlin a écrit :
Hi,
I can understand Dimitri's frustration, it seems the optimization
framework gets worse with every iteration. However, we should
probably look forward and think about how to design it properly
, 2012 7:35:15 PM
Subject: Re: [math] major problem with new released version 3.1
Le 28/12/2012 19:11, Phil Steitz a écrit :
On 12/28/12 9:58 AM, Luc Maisonobe wrote:
Le 28/12/2012 17:51, Konstantin Berlin a écrit :
Hi,
I can understand Dimitri's frustration, it seems the optimization
On 12/28/12 10:35 AM, Luc Maisonobe wrote:
Le 28/12/2012 19:11, Phil Steitz a écrit :
On 12/28/12 9:58 AM, Luc Maisonobe wrote:
Le 28/12/2012 17:51, Konstantin Berlin a écrit :
Hi,
I can understand Dimitri's frustration, it seems the optimization
framework gets worse with every iteration.
Hello,
2012/12/28 Luc Maisonobe luc.maison...@free.fr
Le 28/12/2012 17:51, Konstantin Berlin a écrit :
Hi,
I can understand Dimitri's frustration, it seems the optimization
framework gets worse with every iteration. However, we should
probably look forward and think about how to
Le 28/12/2012 19:47, Phil Steitz a écrit :
On 12/28/12 10:35 AM, Luc Maisonobe wrote:
Le 28/12/2012 19:11, Phil Steitz a écrit :
On 12/28/12 9:58 AM, Luc Maisonobe wrote:
Le 28/12/2012 17:51, Konstantin Berlin a écrit :
Hi,
I can understand Dimitri's frustration, it seems the optimization
That's what I was going to write. At the moment, the current implementation
for sparse matrices and vector is deprecated, for lack of convincing fixes
for the bugs which have been found. These bugs are mainly related to the
fact that zero --the unstored value-- is signed, and the sign is
Hi.
[...]
third is just bug-fix. Does the fix for the issue that started this
thread change the API? If so, we would need to cut 3.2 in any case.
The current fix does change the usage (one needs to call optimize with an
argument of a different type). IIUC, it also silently removes the
On Fri, Dec 28, 2012 at 04:48:59PM +0100, Luc Maisonobe wrote:
Le 28/12/2012 16:08, Dimitri Pourbaix a écrit :
Luc,
However, it is also possible to set a non-diagonal weight matrix, and
one class (AbstractLeastSquaresOptimizer) performs an eigen dcomposition
on the matrix to extract
46 matches
Mail list logo
