To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-scxml-test has an issue affecting its community integration.
This
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-proxy-test has an issue affecting its community integration.
This
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-dbutils has an issue affecting its community integration.
This iss
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-chain2 has an issue affecting its community integration.
This issu
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 whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-digester3 has an issue affecting its community integration.
This i
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
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-dbcp2 has an issue affecting its community integration.
This issue
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-dbcp has an issue affecting its community integration.
This issue
>
> 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
Still no response from infra https://issues.apache.org/jira/browse/INFRA-5657
So I don't know how to start importing content...
What to do is:
* upgrade to parent 28-SNAPSHOT
* add a property exec which
contains the project path relative to commons.a.o
And that's it :-)
parent will need a chan
On Dec 28, 2012, at 15:11, Phil Steitz wrote:
> On 12/28/12 11:44 AM, Gary Gregory wrote:
>> It seems a shame to turn off this feature for ALL projects because one
>> project can't figure out a workaround.
>
> Can *any* project find a workaround? Is there *any way* to turn
> this thing off?
I w
I think the question should be considered with regard to how each OS
deals with this. IIRC Java has a get roots API. I am on my phone ATM
and cannot dig in.
Gary
On Dec 28, 2012, at 15:05, Mark Fortner wrote:
> Hi Gary,
> Good question. There would need to be some OS version checking to
> dete
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 11:44 AM, Gary Gregory wrote:
> It seems a shame to turn off this feature for ALL projects because one
> project can't figure out a workaround.
Can *any* project find a workaround? Is there *any way* to turn
this thing off?
Phil
>
> Gary
>
> On Dec 28, 2012, at 12:21, Phil Steitz wr
Hi Gary,
Good question. There would need to be some OS version checking to
determine which directory to return. I seem to recall that older versions
of Windows had a C:\Documents and Settings folder or something like that.
Currently, I use Spring to config these directories (rather than hard
cod
Hi,
Ok, patches welcome! :)
What happens if there is a c:\Documents folder?
Gary
On Dec 28, 2012, at 14:54, Mark Fortner wrote:
> Hi Gary,
> This would be per operating system. So, if I call
> *RootFactory.getRoot(RootNames.HOME)
> *from a Linux box, that would resolve to */home/*, on a Wind
Hi Gary,
This would be per operating system. So, if I call
*RootFactory.getRoot(RootNames.HOME)
*from a Linux box, that would resolve to */home/*, on a Windows
box that might be */Users/*. It would be driven by the *
System.getProperty("user.home")* variable. The other roots, are OS
dependent an
It seems a shame to turn off this feature for ALL projects because one
project can't figure out a workaround.
Gary
On Dec 28, 2012, at 12:21, Phil Steitz wrote:
> Any objections to this? In [math] at least we can't seem to turn it
> off and it is causing the site build to take forever.
>
> Tha
Would this only be for Windows? What do URIs look like?
Gary
On Dec 28, 2012, at 14:18, Mark Fortner wrote:
> I was wondering if there were any plans (or currently any way) to support
> File System Roots. In addition to the standard sorts of roots, there are
> roots like your home directory, t
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
> > What about 3.1.1 with just the fix for this, then possibly 3.2 or
> > direct to 4.0.
>
> As you want. I don't like adding too many sub-release numbers, just
> as
> if someone fears jumping to next version. I remember some Sun
> products
> and Perl versions that end up with something like 5 rel
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/18/12 2:32 PM, Olivier Lamy wrote:
> 2012/12/18 Olivier Lamy :
>> 2012/12/18 Ralph Goers :
>>> On Dec 18, 2012, at 2:11 PM, Olivier Lamy wrote:
>>>
2012/12/18 Ralph Goers :
> On Dec 18, 2012, at 1:03 PM, Olivier Lamy wrote:
>
>> Maybe could be simpler with committing your sta
Any objections to this? In [math] at least we can't seem to turn it
off and it is causing the site build to take forever.
Thanks!
Phil
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail
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
42 matches
Mail list logo
