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,
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 my problem.
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
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 :
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 :
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
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 :
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
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 has
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 point:
On Nov 30, 2012, at 12:52 PM, Luc Maisonobe luc.maison...@free.fr 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
On Nov 30, 2012, at 1:12 PM, Gilles Sadowski gil...@harfang.homelinux.org
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.
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
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
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 messages, but am
Le 30/11/2012 19:22, Konstantin Berlin a écrit :
On Nov 30, 2012, at 12:52 PM, Luc Maisonobe luc.maison...@free.fr
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
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
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
only
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,
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.
[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 used and
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
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
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 already printed
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
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 arguments
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.
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
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
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
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
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
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
33 matches
Mail list logo
