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-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-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-chain2 has an issue affecting its community integration.
This issu
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
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
Hi,
Now that I have some time, let me try to make my case clearly. First I want to
say that this is not some attack on the automatic-differentation package. I
love automatic-differentation and symbolic packages. I personally cannot
compute a derivative without a computer for the life of me. And
Hi.
> [...]
> >
> > So I suggest we disconnect differentiation from optimization, but in a
> > way that would let users decide how they provide the differentials. This
> > means I would not like to reintroduce the former interfaces.
> >
> > What about having the optimize() methods taking two arg
> >
> > I don't know if people are confused about auto-differentation, I
> > think most people working in numerical analysis are very well aware
> > of what it does. The issue here is that it is a completely separate
> > subject from optimizations. In a proper OO design you would not mix
> > the t
Hi.
> > [...]
> >
> > Of course, _I_ just have to start reading about the subject in order to
> > understand; you are not expected to provide the background within the
> > Javadoc! :-)
>
> If you want some background, read the paper referenced in the API. It is
> really a good paper.
I've alrea
Hello.
>
> I don't know if people are confused about auto-differentation,
> I think most people working in numerical analysis are very well
> aware of what it does. The issue here is that it is a completely
> separate subject from optimizations.
Not completely separate from the optimizer impleme
Le 30/11/2012 20:30, Konstantin Berlin a écrit :
> Hi,
Hi Konstantin,
>
> I don't know if people are confused about auto-differentation, I
> think most people working in numerical analysis are very well aware
> of what it does. The issue here is that it is a completely separate
> subject from op
[changing the subject to something different for this sub-thread]
Le 30/11/2012 20:06, Gilles Sadowski a écrit :
> Hi Luc.
Hi Gilles,
>
>>> As a user of the optimization algorithms I am completely confused by
>>> the change. It seems different from how optimization function are
>>> typically us
Hi,
I don't know if people are confused about auto-differentation, I think most
people working in numerical analysis are very well aware of what it does. The
issue here is that it is a completely separate subject from optimizations. In a
proper OO design you would not mix the two together. Comp
>
Hi,
>
> After your messages, I though we simply needed to simplify our API for
> optimization (and only for optimization) so as to go back to something
> more easy for users, up to not using the differentiation framework at
> all. This seemed reasonable to me. It seems that now you ask for
>
Hi Luc.
> > As a user of the optimization algorithms I am completely confused by
> > the change. It seems different from how optimization function are
> > typically used and seems to be creating a barrier for no reason.
>
> The reason is that the framework has been done for several uses, not
> on
Hi,
How you return the values is not important, though combining the two is kind of
dirty and would make it harder for user. Also it would be kind of complex,
would break OO approach, if you want to return values and the Jacobian, or
extends a base class to gradients and hessians.
I was typing
Le 30/11/2012 19:22, Konstantin Berlin a écrit :
>
> On Nov 30, 2012, at 12:52 PM, Luc Maisonobe
> wrote:
>
>> Hi all,
>>
>> Le 30/11/2012 17:33, Konstantin Berlin a écrit :
>>> As a user of the optimization algorithms I am completely confused
>>> by the change. It seems different from how opti
Le 30/11/2012 19:38, Konstantin Berlin a écrit :
> In my view the framework should be as simple as possible.
>
> class OptimizationFunction
> {
> public DiffValue value(double[] x)
> }
>
> where
>
> class DiffValue
> {
> double val;
> double[] gradient;
> }
I understood your previous mes
In my view the framework should be as simple as possible.
class OptimizationFunction
{
public DiffValue value(double[] x)
}
where
class DiffValue
{
double val;
double[] gradient;
}
class DiffValueHessian
{
double val;
double[] gradient;
double[][] Hesssian;
}
or for least squares
Hi,
This is the part that confuses me. Why are you adding this complexity
layer to optimization framework, specially when this is completely
non-standard way to interface with it? If you want some fancy framework
for differentiation why not created a wrapper function?
I fully agree!
Why wou
On Nov 30, 2012, at 1:12 PM, Gilles Sadowski
wrote:
> Hello.
>
>> As a user of the optimization algorithms I am completely confused by the
>> change. It seems different from how optimization function are typically used
>> and seems to be creating a barrier for no reason.
>
> If you think th
On Nov 30, 2012, at 12:52 PM, Luc Maisonobe wrote:
> Hi all,
>
> Le 30/11/2012 17:33, Konstantin Berlin a écrit :
>> As a user of the optimization algorithms I am completely confused by
>> the change. It seems different from how optimization function are
>> typically used and seems to be creati
Hello.
> As a user of the optimization algorithms I am completely confused by the
> change. It seems different from how optimization function are typically used
> and seems to be creating a barrier for no reason.
If you think that it's for no reason, then you probably missed some
important poin
Hi all,
Le 30/11/2012 17:33, Konstantin Berlin a écrit :
> As a user of the optimization algorithms I am completely confused by
> the change. It seems different from how optimization function are
> typically used and seems to be creating a barrier for no reason.
The reason is that the framework h
As a user of the optimization algorithms I am completely confused by the
change. It seems different from how optimization function are typically used
and seems to be creating a barrier for no reason.
I am not clear why you can't just leave the standard interface to an optimizer
be a function th
Build using Java 1.6
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Continuum-Build-Host: vmbuild
X-Continuum-Project-Id: 83
X-Continuum-Project-Name: Commons IO
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildI
Hello.
Context:
1. A user application computes the Jacobian of a multivariate vector
function (the output of a simulation) using finite differences.
2. The covariance matrix is obtained from "AbstractLeastSquaresOptimizer".
In the new API, the Jacobian is supposed to be "automatically" c
Build using Java 1.6
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Continuum-Build-Host: vmbuild
X-Continuum-Project-Id: 83
X-Continuum-Project-Name: Commons IO
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildI
Build using Java 1.6
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Continuum-Build-Host: vmbuild
X-Continuum-Project-Id: 83
X-Continuum-Project-Name: Commons IO
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildI
Le 29/11/2012 19:12, Matt Benson a écrit :
> This would go back to the idea of something like a BCEL library
> (notwithstanding the fact that the existing privilizer code does not use
> BCEL).
For such a component BCEL would be an implementation detail, so I don't
think it should be a sub part of
Le 30/11/2012 09:19, Thomas Neidhart a écrit :
> On Fri, Nov 30, 2012 at 8:06 AM, Sébastien Brisard <
> sebastien.bris...@m4x.org> wrote:
>
>> Hi,
>> I've already posted the same question in another thread [1], but I thought
>> having a dedicated thread would increase its visibility.
>>
>> Here is
On Fri, Nov 30, 2012 at 8:06 AM, Sébastien Brisard <
sebastien.bris...@m4x.org> wrote:
> Hi,
> I've already posted the same question in another thread [1], but I thought
> having a dedicated thread would increase its visibility.
>
> Here is my problem. The new implementation of Beta.logBeta(double
34 matches
Mail list logo
