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
On Sun, Dec 30, 2012 at 12:16 PM, Konstantin Berlin wrote:
>
> ...
> > 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 additional
On Dec 30, 2012, at 2:26 PM, Sébastien Brisard
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. However...
>
>
> I t
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 th
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
> g
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 wrote:
> I think we might have a misund
Dim has it exactly right here.
On Sun, Dec 30, 2012 at 10:38 AM, Dimitri Pourbaix 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 into a unique scheme (
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 t
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 chan
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 cus
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 wrote:
> Also. If you have GPU implementation of a matrix, or use another type of a
> vector processor,
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 wrote:
> That's a good point about the compiler. I neve
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
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 wrote:
> Actually, the visitor pattern or variant
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 i
>>
>> 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
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,
>> [..
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 s
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 actua
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. Doe
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
>
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 curre
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 deta
Hello,
2012/12/28 Konstantin Berlin
> >
> > 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 z
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 w
Hi,
2012/12/29 Gilles Sadowski
> 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
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
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 th
>
> 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
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
Hello,
2012/12/28 Luc Maisonobe
> 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 prope
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 wi
elopers List"
> Sent: Friday, December 28, 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 Ber
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. However, we should
>>> probably
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 prop
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
On Dec 28, 2012, at 12:23 PM, Dimitri Pourbaix 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
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
>>
>> 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
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
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 o
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
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 the
Phil,
You are certainly welcome to help verify future release candidates,
as well as the commits that go into them.
I did not wait for your kind offer. Gilles got my comments on features I
do use everyday on a huge dataset.
Regards,
Dim.
-
Luc,
Agreed. Dimitri brought out a good point about correlated errors that I didn't
think about. All these cases can be handled by user modifying his/her input,
but it would be nice to think about how this can be supported in the future. I
think this problem showed up for two general reasons, w
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 h
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
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
non-
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 t
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
50 matches
Mail list logo
