Re: [Math] Old to new API ("MultivariateDifferentiable(Vector)Function")

[Thomas Neidhart]

On 12/01/2012 01:42 AM, Konstantin Berlin wrote:
> 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 I am also 
> glad we are finally starting to agree on something :)
> 
> This discussion is about figuring out how an incorrect framework and storage 
> affects the performance of an optimization. That is why I am so worried.
> 
> So lets start with the basics. A Newton method must compute a descent step by 
> solving a linear equation
> 
> H*p = -g, (1)
> 
> where H is the Hessian, g is the gradient, and p is the desired descent step. 
> What I am about to say also holds for non-linear least squares method, where 
> Hessian is approximated using the Jacobian as
> 
> H \approx J^T*J+\lambda I.
> 
> Now, if you are not solving a simple optimization problem that you keep 
> giving examples for, you can easily have a Hessian be a very large matrix,
> like 1000x1000 or larger. Now, you better hope that you are storing H using 
> your linear algebra framework, otherwise eq. (1) computation is going to take 
> a while.
> This is actually a very active area of research, and that is why having 
> sparse linear algebra (aren't you removing this? ;) ) and iterative solvers 
> is important to a lot of people.
> 
> What you are proposing as good OO style is that if someone has a function 
> that they want to optimize, they need to take what is probably already a 
> RealMatrix or [][], and create 1000x1000 DerivativeStructure objects, that,
> within the next 10 lines in the optimizer, are going to be converted back to 
> a RealMatrix? Not only have you just fragmented your heap space, but your 
> garbage collector
> is going crazy, and you are wasting an incredible amount of memory. Now 
> imagine if your Jacobian is actually very simple to compute but large, then 
> this whole conversion back and forth actually takes much longer than the 
> function evaluation.
> 
> So, why exactly are you insisting on taking this performance penalty? You 
> claim that the optimizer can work better if it gets a DerivativeStructure, 
> why? Where is the fact that you are holding a DerivativeStructure come into 
> effect for a Newton method? Can you provide any literature in that regard? 
> The classical optimization bottleneck, if not the actual function evaluation, 
> is eq. (1). The optimization methodology is build on top of years of research 
> in computational linear algebra concepts, and does not care how the matrices 
> are actually computed. Efficient memory usage and speed is critical here 
> because in Newton optimizations eq. (1) is evaluated thousands of times. The 
> goal of the Jacobian is not to store derivatives it is to store a matrix of 
> numbers that allows you to quadratically approximate your target function.
> 
> You guys are focusing on people using finite differences and trying to 
> optimize a newton method to use finite differences. This is not what the main 
> purpose of a newton method is. If you want a method that dynamically adjusts 
> finite differences step size, you should switch to BOBYQA, which was designed 
> for this case.
> 
> Derivatives can be computed by a computer using a symbolic toolbox a priori 
> (something that I was referring to when I accidentally said 
> auto-differenation). They can also be efficiently simplified by that toolbox 
> before being pasted back into you program. Auto-diff could also be an 
> important tool for people if their problem is simple or they are not 
> concerned with optimal efficiency . This can easily be handled by a wrapper 
> and has nothing to do with Newton optimization. If you want to talk about 
> proper OO design and internal simplification then you should focus on being 
> able to pass a linear solver into your optimization method. This way you 
> allow people to use iterative and sparse solvers when needed. If you are 
> concerned about people getting derivatives wrong, you can do what MATLAB 
> does, which is to add an option to check the derivatives using finite 
> differences when debugging. 
> 
> This brings me to my second issue. There are important problems where 
> computation of the derivatives combined with the actual function evaluation 
> is *significantly* faster than computing each alone. I am not clear why I am 
> hitting such resistance with this. For example, you are doing some sort of a 
> simulation, which can be trivially adjusted in the end to give a derivative 
> or a function value. A very real example of this is a Fast Multipole Method, 
> which takes time to compute a series expansion of the function, but the 
> resulting series expansion can be analytically differentiated.
> 
> What I suggested as function interfaces was just an initial quick suggestion 
> that I would be ha

Re: [Math] Old to new API ("MultivariateDifferentiable(Vector)Function")

[Konstantin Berlin]

Hi,

My opinion is that the package should be organized by what it does rather, than 
how it does it. My thinking is

optim
optim.scalar.
optim.scalar.linear
optim.scalar.socp (second order cone programming)'
optim.scalar.qcqp
optim.scalar.nonlinear
optim.scalar.nonlinear.derivfree
optim.scalar.nonlinear.derivfree.Powell, etc
optim.scalar.nonlinear.newton

optim.scalar.univariate.*

optim.leastsquares.linear
optim.leastsquares.nonlinear

But I am flexible. Perhaps it is worth a look here:
http://www.joptimizer.com/


> 
> Shall we also introduce entirely new packages?
> 
> optim
> 
> optim.scalar.noderiv
> optim.scalar.noderiv.PowellOptimizer
> optim.scalar.noderiv.SimplexOptimizer
> optim.scalar.noderiv.CMAESOptimizer
> optim.scalar.noderiv.BOBYQAOptimizer
> 
> optim.scalar.gradient
> optim.scalar.gradient.NonLinearConjugateGradientOptimizer
> 
> optim.vector
> optim.vector.jacobian
> optim.vector.jacobian.AbstractLeastSquaresOptimizer
> optim.vector.jacobian.LevenbergMarquardtOptimizer
> optim.vector.jacobian.GaussNewtonOptimizer
> 
> optim.scalar.univariate.noderiv
> optim.scalar.univariate.noderiv.BrentOptimizer
> 
> 
> Regards,
> Gilles
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] Old to new API ("MultivariateDifferentiable(Vector)Function")

[Sébastien Brisard]

Hi,


2012/12/1 Konstantin Berlin 

> 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 I am also glad we are finally starting to agree on something :)
>
> This discussion is about figuring out how an incorrect framework and
> storage affects the performance of an optimization. That is why I am so
> worried.
>
> So lets start with the basics. A Newton method must compute a descent step
> by solving a linear equation
>
> H*p = -g, (1)
>
> where H is the Hessian, g is the gradient, and p is the desired descent
> step. What I am about to say also holds for non-linear least squares
> method, where Hessian is approximated using the Jacobian as
>
> H \approx J^T*J+\lambda I.
>
> Now, if you are not solving a simple optimization problem that you keep
> giving examples for, you can easily have a Hessian be a very large matrix,
> like 1000x1000 or larger. Now, you better hope that you are storing H
> using your linear algebra framework, otherwise eq. (1) computation is going
> to take a while.
> This is actually a very active area of research, and that is why having
> sparse linear algebra (aren't you removing this? ;) ) and iterative solvers
> is important to a lot of people.
>

A few months ago, we started a thread on this issue (on the users ML). It
got no answers! I am personally not happy with removing the support for
sparse vectors/matrices, but the truth is we didn't see a way to achieve
the same degree of correctness as --say-- array based matrices and vectors.
As far as I am concerned, though, this is still an open question, and if
you have ideas about these issues, we would be glad to here them!


>
> What you are proposing as good OO style is that if someone has a function
> that they want to optimize, they need to take what is probably already a
> RealMatrix or [][], and create 1000x1000 DerivativeStructure objects, that,
> within the next 10 lines in the optimizer, are going to be converted back
> to a RealMatrix? Not only have you just fragmented your heap space, but
> your garbage collector
> is going crazy, and you are wasting an incredible amount of memory. Now
> imagine if your Jacobian is actually very simple to compute but large, then
> this whole conversion back and forth actually takes much longer than the
> function evaluation.
>
> So, why exactly are you insisting on taking this performance penalty? You
> claim that the optimizer can work better if it gets a DerivativeStructure,
> why? Where is the fact that you are holding a DerivativeStructure come into
> effect for a Newton method? Can you provide any literature in that regard?
> The classical optimization bottleneck, if not the actual function
> evaluation, is eq. (1). The optimization methodology is build on top of
> years of research in computational linear algebra concepts, and does not
> care how the matrices are actually computed. Efficient memory usage and
> speed is critical here because in Newton optimizations eq. (1) is evaluated
> thousands of times. The goal of the Jacobian is not to store derivatives it
> is to store a matrix of numbers that allows you to quadratically
> approximate your target function.
>
> You guys are focusing on people using finite differences and trying to
> optimize a newton method to use finite differences. This is not what the
> main purpose of a newton method is. If you want a method that dynamically
> adjusts finite differences step size, you should switch to BOBYQA, which
> was designed for this case.
>
> Derivatives can be computed by a computer using a symbolic toolbox a
> priori (something that I was referring to when I accidentally said
> auto-differenation). They can also be efficiently simplified by that
> toolbox before being pasted back into you program. Auto-diff could also be
> an important tool for people if their problem is simple or they are not
> concerned with optimal efficiency . This can easily be handled by a wrapper
> and has nothing to do with Newton optimization. If you want to talk about
> proper OO design and internal simplification then you should focus on being
> able to pass a linear solver into your optimization method. This way you
> allow people to use iterative and sparse solvers when needed. If you are
> concerned about people getting derivatives wrong, you can do what MATLAB
> does, which is to add an option to check the derivatives using finite
> differences when debugging.
>
> This brings me to my second issue. There are important problems where
> computation of the derivatives combined with the actual function evaluation
> is *significantly* faster than computing each alone. I am not clear why I
> am hitting such resistance with this. For example, you are doing some sort
> of a simulation, which can be triviall

Re: [Math] Old to new API ("MultivariateDifferentiable(Vector)Function")

[Ted Dunning]

Correctness isn't that hard to get.  You just need to add a bitmap for
exceptional values in all matrices.  This bitmap can be accessed by sparse
operations so that the iteration is across the union of non-zero elements
in the sparse vector/matrix and exception elements in the operand.

That fact is, however, that preserving NaN results in these corner cases is
not normally a huge priority for users.  Deleting all support for sparse
vectors, on the other hand, is a huge impact on utility of commons math.
 To my mind deleting hugely useful functionality in the face of a small
issue is upside down, especially when there is actually a pretty simple fix
available.

On Sat, Dec 1, 2012 at 8:02 AM, Sébastien Brisard  wrote:

> A few months ago, we started a thread on this issue (on the users ML). It
> got no answers! I am personally not happy with removing the support for
> sparse vectors/matrices, but the truth is we didn't see a way to achieve
> the same degree of correctness as --say-- array based matrices and vectors.
> As far as I am concerned, though, this is still an open question, and if
> you have ideas about these issues, we would be glad to here them!
>

Re: [Math] Old to new API ("MultivariateDifferentiable(Vector)Function")

[Gilles Sadowski]

Hello.

> 
> 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 I am also 
> glad we are finally starting to agree on something :)

I don't think that we disagreed about the fact that there was a problem with
the interface to the user application. [_I_ started this thread hinting that
there was a problem (at least for me as a user, based on my use-case).]

[Then there were several misunderstandings about what was the problem and how
to solve it...]

> 
> This discussion is about figuring out how an incorrect framework and storage 
> affects the performance of an optimization. That is why I am so worried.

I can understand that this is an important point for your use-case.
There are now two vantage points (at least) on two aspects to consider: You
seem to have experience where storage matter (while I don't); you worry
about "small" objects allocation (while I don't, anymore).

I'm not saying that your worries do not count; quite the contrary. CM is not
my "toolbox"; it's a library based on the knowledge of its developers
(obviously).
If you bring actual use-cases (i.e. unit tests or real application code
that can be benchmarked) that will show worrying behaviour, it will
certainly trigger swift corrective action. [This has happened recently.]

In this area (performance), the problem is that intuition (or educated
guess, however you want to name it) is not a substitute for actual runs,
sometimes by a large amount. [When I started to use CM, I raised the issue
that a 3D vector was immutable (so that I had to create a new one whenever
its coordinates were changing). Surely this was a performance hit! Actually
it wasn't.]

Again, that does not mean that you are wrong in this case. It's just that we
cannot jump and change the code every time someone comes up with what
amounts to "conventional wisdom". If the person comes with a patch that
readily proves the point (at least marginally through microbenchmarking),
then we all benefit.

> 
> So lets start with the basics. A Newton method must compute a descent step by 
> solving a linear equation
> 
> H*p = -g, (1)
> 
> where H is the Hessian, g is the gradient, and p is the desired descent step. 
> What I am about to say also holds for non-linear least squares method, where 
> Hessian is approximated using the Jacobian as
> 
> H \approx J^T*J+\lambda I.
> 
> Now, if you are not solving a simple optimization problem that you keep 
> giving examples for, you can easily have a Hessian be a very large matrix,
> like 1000x1000 or larger. Now, you better hope that you are storing H using 
> your linear algebra framework, otherwise eq. (1) computation is going to take 
> a while.
> This is actually a very active area of research, and that is why having 
> sparse linear algebra (aren't you removing this? ;) ) and iterative solvers 
> is important to a lot of people.

Yes we are removing it because it is buggy and _nobody_ stepped up to say
that it was important for CM users, and to help solve the problems in a way
consistent with real-life usage of such a feature.
As Sébastien said, you are warmly welcome to help us find a way to keep the
feature.

> 
> What you are proposing as good OO style 

This discussion has really nothing to do with "OO style", merely code reuse;
and it was my big misunderstanding (partly because of my lack of knowledge,
partly because of the lack of documentation on the targetted usages of
"DerivativeStructure", which IIUC now, are outside CM) that I believed
that the new "MultivariateDifferentiableFunction" was the way to go.

[Also, Luc had been moving very fast on this. And I couldn't keep up
although I had wondered earlier why this had to impact usage in the
"optimization" package.]

> is that if someone has a function that they want to optimize, they need to 
> take what is probably already a RealMatrix or [][], and create 1000x1000 
> DerivativeStructure objects, that,

IIUC, that would be 1000 "DerivativeStructure" (not 1000x1000). If so, for
this example, using "DerivativeStructure" would lead to about a 4% increase
in storage memory.

> within the next 10 lines in the optimizer, are going to be converted back to 
> a RealMatrix? Not only have you just fragmented your heap space, but your 
> garbage collector
> is going crazy, and you are wasting an incredible amount of memory.

This is the kind of assertions that really needs support from actual code.
[Again, I don't claim to know better; I think that it would really be useful
to accumulate a list of "do and don't" for Java and CM, in the form of
reproducible user experience.]

> Now imagine if your Jacobian is actually very simple to compute but large, 
> then this whole conversion back and forth actually takes much longer than the 
> function

Re: [Math] Old to new API ("MultivariateDifferentiable(Vector)Function")

[Gilles Sadowski]

On Sat, Dec 01, 2012 at 09:59:37AM -0800, Ted Dunning wrote:
> Correctness isn't that hard to get.  You just need to add a bitmap for
> exceptional values in all matrices.  This bitmap can be accessed by sparse
> operations so that the iteration is across the union of non-zero elements
> in the sparse vector/matrix and exception elements in the operand.
> 
> That fact is, however, that preserving NaN results in these corner cases is
> not normally a huge priority for users.  Deleting all support for sparse
> vectors, on the other hand, is a huge impact on utility of commons math.
>  To my mind deleting hugely useful functionality in the face of a small
> issue is upside down, especially when there is actually a pretty simple fix
> available.

Huge impact? It didn't seem so, since _nobody_ answered a recent poll about
deleting the sparse arrays feature.


Regards,
Gilles

P.S. There are other Java libraries which, last time I looked, seem to focus
 much more on the storage flexibility viewpoint than does CM (e.g.
 OjALgo).

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] Old to new API ("MultivariateDifferentiable(Vector)Function")

[Konstantin Berlin]

Hi,



> Hello.
> 
>> 
>> 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 I am also 
>> glad we are finally starting to agree on something :)
> 
> I don't think that we disagreed about the fact that there was a problem with
> the interface to the user application. [_I_ started this thread hinting that
> there was a problem (at least for me as a user, based on my use-case).]
> 
> [Then there were several misunderstandings about what was the problem and how
> to solve it...]
> 
>> 
>> This discussion is about figuring out how an incorrect framework and storage 
>> affects the performance of an optimization. That is why I am so worried.
> 
> I can understand that this is an important point for your use-case.
> There are now two vantage points (at least) on two aspects to consider: You
> seem to have experience where storage matter (while I don't); you worry
> about "small" objects allocation (while I don't, anymore).
> 
> I'm not saying that your worries do not count; quite the contrary. CM is not
> my "toolbox"; it's a library based on the knowledge of its developers
> (obviously).
> If you bring actual use-cases (i.e. unit tests or real application code
> that can be benchmarked) that will show worrying behaviour, it will
> certainly trigger swift corrective action. [This has happened recently.]
> 
> In this area (performance), the problem is that intuition (or educated
> guess, however you want to name it) is not a substitute for actual runs,
> sometimes by a large amount. [When I started to use CM, I raised the issue
> that a 3D vector was immutable (so that I had to create a new one whenever
> its coordinates were changing). Surely this was a performance hit! Actually
> it wasn't.]

This is not the same case. You take a function that a user normally expresses 
as a two dimensional array or a vector, you force them to allocate 10K+ new 
objects that you then have to unwrap back into the structure the user would 
have happily supplied you in the first place. The second issue you missed is 
one of scale. The difference between modifying a 3 variable array and creating 
a copy is not large. Try doing this with a 10k+ vector, where you don't 
actually need to modify any of the entries but are just doing copies for the 
hell of it. This is a known critical component of an optimization and should be 
optimized for performance itself.

> 
> Again, that does not mean that you are wrong in this case. It's just that we
> cannot jump and change the code every time someone comes up with what
> amounts to "conventional wisdom". If the person comes with a patch that
> readily proves the point (at least marginally through microbenchmarking),
> then we all benefit.
> 

This is not "conventional wisdom", this is 60 years of research, so you better 
provide a good reason for you increased level of abstraction. I asked you why 
you would indirectly wrap a Hessian or a Jacobian in a much heaver class that 
provides no useful features for a newton optimizer. I don't think you gave me 
an answer. I do not believe that good OO design is to have as many abstract 
layers as you can think of. Good OO design is just like any good engineering 
design, its about having things clean, simple, and not be dependent on 
components that are not required. In addition, if you are working on a code 
that is called thousands of times, you should think really careful about memory 
performance.

>> 
>> So lets start with the basics. A Newton method must compute a descent step 
>> by solving a linear equation
>> 
>> H*p = -g, (1)
>> 
>> where H is the Hessian, g is the gradient, and p is the desired descent 
>> step. What I am about to say also holds for non-linear least squares method, 
>> where Hessian is approximated using the Jacobian as
>> 
>> H \approx J^T*J+\lambda I.
>> 
>> Now, if you are not solving a simple optimization problem that you keep 
>> giving examples for, you can easily have a Hessian be a very large matrix,
>> like 1000x1000 or larger. Now, you better hope that you are storing H using 
>> your linear algebra framework, otherwise eq. (1) computation is going to 
>> take a while.
>> This is actually a very active area of research, and that is why having 
>> sparse linear algebra (aren't you removing this? ;) ) and iterative solvers 
>> is important to a lot of people.
> 
> Yes we are removing it because it is buggy and _nobody_ stepped up to say
> that it was important for CM users, and to help solve the problems in a way
> consistent with real-life usage of such a feature.
> As Sébastien said, you are warmly welcome to help us find a way to keep the
> feature.

I personally do not use sparse linear algebra. I was just pointing out how 
important computation of eq. 1 is in g

Re: [Math] Old to new API ("MultivariateDifferentiable(Vector)Function")

[Konstantin Berlin]

I forgot to say that there are commonly used benchmarks for optimization 
algorithm developers. They are commonly used to compare different algorithms in 
publications. I am personally not familiar with them, but it would be easy to 
google them.

On Dec 1, 2012, at 1:31 PM, Gilles Sadowski  
wrote:

> Hello.
> 
>> 
>> 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 I am also 
>> glad we are finally starting to agree on something :)
> 
> I don't think that we disagreed about the fact that there was a problem with
> the interface to the user application. [_I_ started this thread hinting that
> there was a problem (at least for me as a user, based on my use-case).]
> 
> [Then there were several misunderstandings about what was the problem and how
> to solve it...]
> 
>> 
>> This discussion is about figuring out how an incorrect framework and storage 
>> affects the performance of an optimization. That is why I am so worried.
> 
> I can understand that this is an important point for your use-case.
> There are now two vantage points (at least) on two aspects to consider: You
> seem to have experience where storage matter (while I don't); you worry
> about "small" objects allocation (while I don't, anymore).
> 
> I'm not saying that your worries do not count; quite the contrary. CM is not
> my "toolbox"; it's a library based on the knowledge of its developers
> (obviously).
> If you bring actual use-cases (i.e. unit tests or real application code
> that can be benchmarked) that will show worrying behaviour, it will
> certainly trigger swift corrective action. [This has happened recently.]
> 
> In this area (performance), the problem is that intuition (or educated
> guess, however you want to name it) is not a substitute for actual runs,
> sometimes by a large amount. [When I started to use CM, I raised the issue
> that a 3D vector was immutable (so that I had to create a new one whenever
> its coordinates were changing). Surely this was a performance hit! Actually
> it wasn't.]
> 
> Again, that does not mean that you are wrong in this case. It's just that we
> cannot jump and change the code every time someone comes up with what
> amounts to "conventional wisdom". If the person comes with a patch that
> readily proves the point (at least marginally through microbenchmarking),
> then we all benefit.
> 
>> 
>> So lets start with the basics. A Newton method must compute a descent step 
>> by solving a linear equation
>> 
>> H*p = -g, (1)
>> 
>> where H is the Hessian, g is the gradient, and p is the desired descent 
>> step. What I am about to say also holds for non-linear least squares method, 
>> where Hessian is approximated using the Jacobian as
>> 
>> H \approx J^T*J+\lambda I.
>> 
>> Now, if you are not solving a simple optimization problem that you keep 
>> giving examples for, you can easily have a Hessian be a very large matrix,
>> like 1000x1000 or larger. Now, you better hope that you are storing H using 
>> your linear algebra framework, otherwise eq. (1) computation is going to 
>> take a while.
>> This is actually a very active area of research, and that is why having 
>> sparse linear algebra (aren't you removing this? ;) ) and iterative solvers 
>> is important to a lot of people.
> 
> Yes we are removing it because it is buggy and _nobody_ stepped up to say
> that it was important for CM users, and to help solve the problems in a way
> consistent with real-life usage of such a feature.
> As Sébastien said, you are warmly welcome to help us find a way to keep the
> feature.
> 
>> 
>> What you are proposing as good OO style 
> 
> This discussion has really nothing to do with "OO style", merely code reuse;
> and it was my big misunderstanding (partly because of my lack of knowledge,
> partly because of the lack of documentation on the targetted usages of
> "DerivativeStructure", which IIUC now, are outside CM) that I believed
> that the new "MultivariateDifferentiableFunction" was the way to go.
> 
> [Also, Luc had been moving very fast on this. And I couldn't keep up
> although I had wondered earlier why this had to impact usage in the
> "optimization" package.]
> 
>> is that if someone has a function that they want to optimize, they need to 
>> take what is probably already a RealMatrix or [][], and create 1000x1000 
>> DerivativeStructure objects, that,
> 
> IIUC, that would be 1000 "DerivativeStructure" (not 1000x1000). If so, for
> this example, using "DerivativeStructure" would lead to about a 4% increase
> in storage memory.
> 
>> within the next 10 lines in the optimizer, are going to be converted back to 
>> a RealMatrix? Not only have you just fragmented your heap space, but your 
>> garbage collector
>> is going crazy, and you are wasting

Re: [Math] Old to new API ("MultivariateDifferentiable(Vector)Function")

[Luc Maisonobe]

Konstantin Berlin  a écrit :

>Hi,
>
>
>
>> Hello.
>> 
>>> 
>>> 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 I am also glad we are finally starting
>to agree on something :)
>> 
>> I don't think that we disagreed about the fact that there was a
>problem with
>> the interface to the user application. [_I_ started this thread
>hinting that
>> there was a problem (at least for me as a user, based on my
>use-case).]
>> 
>> [Then there were several misunderstandings about what was the problem
>and how
>> to solve it...]
>> 
>>> 
>>> This discussion is about figuring out how an incorrect framework and
>storage affects the performance of an optimization. That is why I am so
>worried.
>> 
>> I can understand that this is an important point for your use-case.
>> There are now two vantage points (at least) on two aspects to
>consider: You
>> seem to have experience where storage matter (while I don't); you
>worry
>> about "small" objects allocation (while I don't, anymore).
>> 
>> I'm not saying that your worries do not count; quite the contrary. CM
>is not
>> my "toolbox"; it's a library based on the knowledge of its developers
>> (obviously).
>> If you bring actual use-cases (i.e. unit tests or real application
>code
>> that can be benchmarked) that will show worrying behaviour, it will
>> certainly trigger swift corrective action. [This has happened
>recently.]
>> 
>> In this area (performance), the problem is that intuition (or
>educated
>> guess, however you want to name it) is not a substitute for actual
>runs,
>> sometimes by a large amount. [When I started to use CM, I raised the
>issue
>> that a 3D vector was immutable (so that I had to create a new one
>whenever
>> its coordinates were changing). Surely this was a performance hit!
>Actually
>> it wasn't.]
>
>This is not the same case. You take a function that a user normally
>expresses as a two dimensional array or a vector, you force them to
>allocate 10K+ new objects that you then have to unwrap back into the
>structure the user would have happily supplied you in the first place.
>The second issue you missed is one of scale. The difference between
>modifying a 3 variable array and creating a copy is not large. Try
>doing this with a 10k+ vector, where you don't actually need to modify
>any of the entries but are just doing copies for the hell of it. This
>is a known critical component of an optimization and should be
>optimized for performance itself.
>
>> 
>> Again, that does not mean that you are wrong in this case. It's just
>that we
>> cannot jump and change the code every time someone comes up with what
>> amounts to "conventional wisdom". If the person comes with a patch
>that
>> readily proves the point (at least marginally through
>microbenchmarking),
>> then we all benefit.
>> 
>
>This is not "conventional wisdom", this is 60 years of research, so you
>better provide a good reason for you increased level of abstraction. I
>asked you why you would indirectly wrap a Hessian or a Jacobian in a
>much heaver class that provides no useful features for a newton
>optimizer. I don't think you gave me an answer. I do not believe that
>good OO design is to have as many abstract layers as you can think of.
>Good OO design is just like any good engineering design, its about
>having things clean, simple, and not be dependent on components that
>are not required. In addition, if you are working on a code that is
>called thousands of times, you should think really careful about memory
>performance.
>
>>> 
>>> So lets start with the basics. A Newton method must compute a
>descent step by solving a linear equation
>>> 
>>> H*p = -g, (1)
>>> 
>>> where H is the Hessian, g is the gradient, and p is the desired
>descent step. What I am about to say also holds for non-linear least
>squares method, where Hessian is approximated using the Jacobian as
>>> 
>>> H \approx J^T*J+\lambda I.
>>> 
>>> Now, if you are not solving a simple optimization problem that you
>keep giving examples for, you can easily have a Hessian be a very large
>matrix,
>>> like 1000x1000 or larger. Now, you better hope that you are storing
>H using your linear algebra framework, otherwise eq. (1) computation is
>going to take a while.
>>> This is actually a very active area of research, and that is why
>having sparse linear algebra (aren't you removing this? ;) ) and
>iterative solvers is important to a lot of people.
>> 
>> Yes we are removing it because it is buggy and _nobody_ stepped up to
>say
>> that it was important for CM users, and to help solve the problems in
>a way
>> consistent with real-life usage of such a feature.
>> As Sébastien said, you are warmly welcome to help us find a way to
>keep the
>> feature.
>
>I personally do not use s

Re: [Math] Old to new API ("MultivariateDifferentiable(Vector)Function")

[Gilles Sadowski]

Hello.

> 
> My opinion is that the package should be organized by what it does rather, 
> than how it does it.

My proposal is based on what the user wants to do and on what input is
required in order to use the tools in the given package, where all
algorithms will share the same interface.

> My thinking is
> 
> optim
> optim.scalar.
> optim.scalar.linear
> optim.scalar.socp (second order cone programming)'
> optim.scalar.qcqp
> optim.scalar.nonlinear
> optim.scalar.nonlinear.derivfree
> optim.scalar.nonlinear.derivfree.Powell, etc
> optim.scalar.nonlinear.newton
> 
> optim.scalar.univariate.*
> 
> optim.leastsquares.linear
> optim.leastsquares.nonlinear

IMHO, the problem with the above is that it is targetted to optimization
experts (who would know what all the abbreviations mean and what to look
for).
In the other approach, a non-expert can go to a package, read the top-level
doc and start experimenting, knowing what to plug in. [I know, this is not
a strong argument; but it lowers the barrier to entry. :-)]

Perhaps there are intersections between the two approaches.

> But I am flexible. Perhaps it is worth a look here:
> http://www.joptimizer.com/

Thanks for the pointer.

Gilles

> 
> > 
> > Shall we also introduce entirely new packages?
> > 
> > optim
> > 
> > optim.scalar.noderiv
> > optim.scalar.noderiv.PowellOptimizer
> > optim.scalar.noderiv.SimplexOptimizer
> > optim.scalar.noderiv.CMAESOptimizer
> > optim.scalar.noderiv.BOBYQAOptimizer
> > 
> > optim.scalar.gradient
> > optim.scalar.gradient.NonLinearConjugateGradientOptimizer
> > 
> > optim.vector
> > optim.vector.jacobian
> > optim.vector.jacobian.AbstractLeastSquaresOptimizer
> > optim.vector.jacobian.LevenbergMarquardtOptimizer
> > optim.vector.jacobian.GaussNewtonOptimizer
> > 
> > optim.scalar.univariate.noderiv
> > optim.scalar.univariate.noderiv.BrentOptimizer
> > 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Using reflection to test private methods

[sebb]

On 30 November 2012 11:43, Luc Maisonobe  wrote:
> 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. The new implementation of Beta.logBeta(double, double)
>>> I'm currently working on relies on several private methods through a rather
>>> complex branching.
>>> Due to this complicated branching, I find it much safer to have direct
>>> tests for these private methods, instead of relying on the tests of
>>> Beta.logBeta to validate these methods.
>>> Therefore, in order to preserve encapsulation (these private methods should
>>> really remain private, and not package private, as I previously did [2]), I
>>> propose to use reflection in the unit tests to access these private
>>> methods. I've tested this option locally, it seems to me that it is a
>>> viable option.
>>>
>>> What do you think about this compromise?
>>>
>>
>> imho, this is perfectly valid in such a specific case, and I had to do the
>> same in other projects occasionally.
>
> +1, and I used the same trick already in some projects.

+1 to using reflection in test cases if necessary.
[I don't see why that even needs a vote!]

However, I don't see what the issue is with package-private methods,
so long as the reason for the removal of the private qualifier is
documented.

If 3rd party application code creates classes in o.a.c.m packages,
then any problems that result are entirely up to them to resolve...

> Luc
>
>>
>> Thomas
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] Old to new API ("MultivariateDifferentiable(Vector)Function")

[Konstantin Berlin]

> 
> I would propose to simply revert my changes on the optimization package 
> and prepare for a reorganization for 4.0. I understand I focused only on
> the type of problems Gilles and myself routinely use, i .e. small size 
> problems 
> where the cost of the evaluation is several orders of magnitude larger than 
> the
> data copying. I forgot the dual case with  very large data sets. I apologize 
> for that. 
> 
> When 3.1 will be out, we will have to solve this so both  cases are handled 
> efficiently, 
> and this would probably be implemented in 4.0.
> 
> Does this seems reasonable? 
> 
> Best regards 
> Luc
> 

Don't blame yourself, its hard to think of all possible uses. I think reverting 
back to original interface is the best choice for 3.1. In the future it is 
worth finding and adding "standard" industry benchmarks to the tests.

Speaking of optimizers... Would it not be better to move all the getRMS, 
getChiSquared into the return class, along with all other information, like how 
many iterations it took, function evaluations, etc? That is how I find it more 
natural to use, so I end up creating a wrapper. These properties are not 
properties of the optimizer but are properties of the specific optimization 
evaluation of the function with the specific initial value.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release NET 3.2 based on RC1

[sebb]

On 28 November 2012 06:29, Gary Gregory  wrote:
> On Mon, Nov 26, 2012 at 2:20 PM, sebb  wrote:
>
>> On 26 November 2012 19:08, Gary Gregory  wrote:
>> > Hi,
>> >
>> > I thought we had a policy to keep BC for minor releases?
>>
>> Yes.
>>
>> > I understand that the removed methods are not in core classes but it
>> still
>> > breaks BC. Are sure we want that? Are the removed methods confusing in a
>> > way that can be construed as keeping them being a bug?
>>
>> If the code is not being used by external clients then BC
>> compatibility is irrelevant.
>> This is the case here.
>>
>
> +1

Is that a +1 to release or a +1 to my comment only?

Just want to be sure; if it is +1 to release I can close the vote and
proceeed with the release.

> Gary
>
>
>>
>> > Gary
>> >
>> > On Mon, Nov 26, 2012 at 1:29 PM, sebb  wrote:
>> >
>> >> This is a vote to release Apache Commons NET 3.2 based on RC1.
>> >>
>> >> [ ] +1 release it
>> >> [ ] +0 go ahead I don't care
>> >> [ ] -1 no, do not release it because...
>> >>
>> >> tag:
>> >>
>> https://svn.apache.org/repos/asf/commons/proper/net/tags/NET_3_2_RC1/(r1413727)
>> >>
>> >> site:
>> >> http://people.apache.org/~sebb/net-3.2-RC1/
>> >>
>> >> The Javadocs (1.4.1) link does not work, nor does the download link.
>> >> These will be OK once the site is deployed.
>> >>
>> >> Source and binary archives (tar.gz and .zip) and Maven jars:
>> >>
>> https://repository.apache.org/content/repositories/orgapachecommons-078/
>> >>
>> >> [The tar.gz and .zip files will be moved to dist/commons/net before
>> >> promoting the Maven jars to release status]
>> >>
>> >> Vote will remain open for at least 72 hours.
>> >>
>> >> -
>> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >> For additional commands, e-mail: dev-h...@commons.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> > JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>> > Spring Batch in Action: http://bit.ly/bqpbCK
>> > Blog: http://garygregory.wordpress.com
>> > Home: http://garygregory.com/
>> > Tweet! http://twitter.com/GaryGregory
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release NET 3.2 based on RC1

[sebb]

On 26 November 2012 18:29, sebb  wrote:
> This is a vote to release Apache Commons NET 3.2 based on RC1.
>
> [X] +1 release it
> [ ] +0 go ahead I don't care
> [ ] -1 no, do not release it because...

Adding my vote.

> tag:
> https://svn.apache.org/repos/asf/commons/proper/net/tags/NET_3_2_RC1/ 
> (r1413727)
>
> site:
> http://people.apache.org/~sebb/net-3.2-RC1/
>
> The Javadocs (1.4.1) link does not work, nor does the download link.
> These will be OK once the site is deployed.
>
> Source and binary archives (tar.gz and .zip) and Maven jars:
> https://repository.apache.org/content/repositories/orgapachecommons-078/
>
> [The tar.gz and .zip files will be moved to dist/commons/net before
> promoting the Maven jars to release status]
>
> Vote will remain open for at least 72 hours.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] Old to new API ("MultivariateDifferentiable(Vector)Function")

[Konstantin Berlin]

>> 
>> My opinion is that the package should be organized by what it does rather, 
>> than how it does it.
> 
> My proposal is based on what the user wants to do and on what input is
> required in order to use the tools in the given package, where all
> algorithms will share the same interface.
> 

I humbly disagree with your claim. The user does not want a vector nor a 
Jcobian. The user has a problem, and they want to see their options for a 
solution. That is why they will go into, for example, least-squares. They will 
see that there are different kinds, so they will go into linear, for example. 
There they will see all their options and what they need to make it work.

I also have a problem with how you targeting the package to naive people who 
want to play around with packages. You want the package to be easily accessible 
to people who require optimizations. I would imagine most users have a good 
idea what kind of problem that they have are looking for the optimizer that 
will solve their problem. By structuring the packages in the way I describe, 
they first go through the general problem that they have, and then go down into 
more specific detail with every level. That seems to me the most natural.

>> My thinking is
>> 
>> optim
>> optim.scalar.
>> optim.scalar.linear
>> optim.scalar.socp (second order cone programming)'
>> optim.scalar.qcqp
>> optim.scalar.nonlinear
>> optim.scalar.nonlinear.derivfree
>> optim.scalar.nonlinear.derivfree.Powell, etc
>> optim.scalar.nonlinear.newton
>> 
>> optim.scalar.univariate.*
>> 
>> optim.leastsquares.linear
>> optim.leastsquares.nonlinear
> 
> IMHO, the problem with the above is that it is targetted to optimization
> experts (who would know what all the abbreviations mean and what to look
> for).
> In the other approach, a non-expert can go to a package, read the top-level
> doc and start experimenting, knowing what to plug in. [I know, this is not
> a strong argument; but it lowers the barrier to entry. :-)]
> 
> Perhaps there are intersections between the two approaches.
> 
>> But I am flexible. Perhaps it is worth a look here:
>> http://www.joptimizer.com/
> 
> Thanks for the pointer.
> 
> Gilles
> 
>> 
>>> 
>>> Shall we also introduce entirely new packages?
>>> 
>>> optim
>>> 
>>> optim.scalar.noderiv
>>> optim.scalar.noderiv.PowellOptimizer
>>> optim.scalar.noderiv.SimplexOptimizer
>>> optim.scalar.noderiv.CMAESOptimizer
>>> optim.scalar.noderiv.BOBYQAOptimizer
>>> 
>>> optim.scalar.gradient
>>> optim.scalar.gradient.NonLinearConjugateGradientOptimizer
>>> 
>>> optim.vector
>>> optim.vector.jacobian
>>> optim.vector.jacobian.AbstractLeastSquaresOptimizer
>>> optim.vector.jacobian.LevenbergMarquardtOptimizer
>>> optim.vector.jacobian.GaussNewtonOptimizer
>>> 
>>> optim.scalar.univariate.noderiv
>>> optim.scalar.univariate.noderiv.BrentOptimizer
>>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release NET 3.2 based on RC1

[Gary Gregory]

On Sat, Dec 1, 2012 at 5:04 PM, sebb  wrote:

> On 28 November 2012 06:29, Gary Gregory  wrote:
> > On Mon, Nov 26, 2012 at 2:20 PM, sebb  wrote:
> >
> >> On 26 November 2012 19:08, Gary Gregory  wrote:
> >> > Hi,
> >> >
> >> > I thought we had a policy to keep BC for minor releases?
> >>
> >> Yes.
> >>
> >> > I understand that the removed methods are not in core classes but it
> >> still
> >> > breaks BC. Are sure we want that? Are the removed methods confusing
> in a
> >> > way that can be construed as keeping them being a bug?
> >>
> >> If the code is not being used by external clients then BC
> >> compatibility is irrelevant.
> >> This is the case here.
> >>
> >
> > +1
>
> Is that a +1 to release or a +1 to my comment only?
>

This is a +1 to release. I am going by your experience as to the safety of
removing the methods, so I ACK you comment I could say.

Gary


>
> Just want to be sure; if it is +1 to release I can close the vote and
> proceeed with the release.
>
> > Gary
> >
> >
> >>
> >> > Gary
> >> >
> >> > On Mon, Nov 26, 2012 at 1:29 PM, sebb  wrote:
> >> >
> >> >> This is a vote to release Apache Commons NET 3.2 based on RC1.
> >> >>
> >> >> [ ] +1 release it
> >> >> [ ] +0 go ahead I don't care
> >> >> [ ] -1 no, do not release it because...
> >> >>
> >> >> tag:
> >> >>
> >>
> https://svn.apache.org/repos/asf/commons/proper/net/tags/NET_3_2_RC1/(r1413727)
> >> >>
> >> >> site:
> >> >> http://people.apache.org/~sebb/net-3.2-RC1/
> >> >>
> >> >> The Javadocs (1.4.1) link does not work, nor does the download link.
> >> >> These will be OK once the site is deployed.
> >> >>
> >> >> Source and binary archives (tar.gz and .zip) and Maven jars:
> >> >>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-078/
> >> >>
> >> >> [The tar.gz and .zip files will be moved to dist/commons/net before
> >> >> promoting the Maven jars to release status]
> >> >>
> >> >> Vote will remain open for at least 72 hours.
> >> >>
> >> >> -
> >> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> >> > JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> >> > Spring Batch in Action: http://bit.ly/bqpbCK
> >> > Blog: http://garygregory.wordpress.com
> >> > Home: http://garygregory.com/
> >> > Tweet! http://twitter.com/GaryGregory
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >>
> >
> >
> > --
> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> > Spring Batch in Action: http://bit.ly/bqpbCK
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [Math] Old to new API ("MultivariateDifferentiable(Vector)Function")

[Gilles Sadowski]

Hello.

> > 
> >> 
> >> 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 I am also glad we are finally starting to agree on something :)
> > 
> > I don't think that we disagreed about the fact that there was a problem with
> > the interface to the user application. [_I_ started this thread hinting that
> > there was a problem (at least for me as a user, based on my use-case).]
> > 
> > [Then there were several misunderstandings about what was the problem and 
> > how
> > to solve it...]
> > 
> >> 
> >> This discussion is about figuring out how an incorrect framework and 
> >> storage affects the performance of an optimization. That is why I am so 
> >> worried.
> > 
> > I can understand that this is an important point for your use-case.
> > There are now two vantage points (at least) on two aspects to consider: You
> > seem to have experience where storage matter (while I don't); you worry
> > about "small" objects allocation (while I don't, anymore).
> > 
> > I'm not saying that your worries do not count; quite the contrary. CM is not
> > my "toolbox"; it's a library based on the knowledge of its developers
> > (obviously).
> > If you bring actual use-cases (i.e. unit tests or real application code
> > that can be benchmarked) that will show worrying behaviour, it will
> > certainly trigger swift corrective action. [This has happened recently.]
> > 
> > In this area (performance), the problem is that intuition (or educated
> > guess, however you want to name it) is not a substitute for actual runs,
> > sometimes by a large amount. [When I started to use CM, I raised the issue
> > that a 3D vector was immutable (so that I had to create a new one whenever
> > its coordinates were changing). Surely this was a performance hit! Actually
> > it wasn't.]
> 
> This is not the same case. You take a function that a user normally expresses 
> as a two dimensional array or a vector, you force them to allocate 10K+ new 
> objects that you then have to unwrap back into the structure the user would 
> have happily supplied you in the first place. The second issue you missed is 
> one of scale. The difference between modifying a 3 variable array and 
> creating a copy is not large. Try doing this with a 10k+ vector, where you 
> don't actually need to modify any of the entries but are just doing copies 
> for the hell of it. This is a known critical component of an optimization and 
> should be optimized for performance itself.

It's always not the same case (really). The crux of the example was about
(my) misconception about what takes time in a JVM.
In CM, there are tons of unneeded (from your point-of-view) copying because
in most cases, it was deemed worth in order to ensure the integrity of the
subsequent processing.
And we also noticed that in the "usual" (the developers' use-cases), it did
not matter much. [And where it does, then we try to take it into account.]

> 
> > 
> > Again, that does not mean that you are wrong in this case. It's just that we
> > cannot jump and change the code every time someone comes up with what
> > amounts to "conventional wisdom". If the person comes with a patch that
> > readily proves the point (at least marginally through microbenchmarking),
> > then we all benefit.
> > 
> 
> This is not "conventional wisdom", this is 60 years of research, so you 
> better provide a good reason for you increased level of abstraction. I asked 
> you why you would indirectly wrap a Hessian or a Jacobian in a much heaver 
> class that provides no useful features for a newton optimizer. I don't think 
> you gave me an answer. I do not believe that good OO design is to have as 
> many abstract layers as you can think of. Good OO design is just like any 
> good engineering design, its about having things clean, simple, and not be 
> dependent on components that are not required. In addition, if you are 
> working on a code that is called thousands of times, you should think really 
> careful about memory performance.

I only talked about code reuse (internally). This should not have impacted
users (i.e. require them to learn about "DerivativeStructure"). Luc already
said that _this_ (what I say in the provious sentence) is was not necessary.
We are not trying to get one step further. Please forget about
"DerivativeStructure".

> 
> >> 
> >> So lets start with the basics. A Newton method must compute a descent step 
> >> by solving a linear equation
> >> 
> >> H*p = -g, (1)
> >> 
> >> where H is the Hessian, g is the gradient, and p is the desired descent 
> >> step. What I am about to say also holds for non-linear least squares 
> >> method, where Hessian is approximated using the Jacobian as
> >> 
> >> H \approx J^T*J+\lambda I.
> >> 
> >> 

Re: [VOTE] Release NET 3.2 based on RC1

[sebb]

On 1 December 2012 22:14, Gary Gregory  wrote:
> On Sat, Dec 1, 2012 at 5:04 PM, sebb  wrote:
>
>> On 28 November 2012 06:29, Gary Gregory  wrote:
>> > On Mon, Nov 26, 2012 at 2:20 PM, sebb  wrote:
>> >
>> >> On 26 November 2012 19:08, Gary Gregory  wrote:
>> >> > Hi,
>> >> >
>> >> > I thought we had a policy to keep BC for minor releases?
>> >>
>> >> Yes.
>> >>
>> >> > I understand that the removed methods are not in core classes but it
>> >> still
>> >> > breaks BC. Are sure we want that? Are the removed methods confusing
>> in a
>> >> > way that can be construed as keeping them being a bug?
>> >>
>> >> If the code is not being used by external clients then BC
>> >> compatibility is irrelevant.
>> >> This is the case here.
>> >>
>> >
>> > +1
>>
>> Is that a +1 to release or a +1 to my comment only?
>>
>
> This is a +1 to release. I am going by your experience as to the safety of
> removing the methods, so I ACK you comment I could say.

OK, thanks, I'll close the vote & proceed.

> Gary
>
>
>>
>> Just want to be sure; if it is +1 to release I can close the vote and
>> proceeed with the release.
>>
>> > Gary
>> >
>> >
>> >>
>> >> > Gary
>> >> >
>> >> > On Mon, Nov 26, 2012 at 1:29 PM, sebb  wrote:
>> >> >
>> >> >> This is a vote to release Apache Commons NET 3.2 based on RC1.
>> >> >>
>> >> >> [ ] +1 release it
>> >> >> [ ] +0 go ahead I don't care
>> >> >> [ ] -1 no, do not release it because...
>> >> >>
>> >> >> tag:
>> >> >>
>> >>
>> https://svn.apache.org/repos/asf/commons/proper/net/tags/NET_3_2_RC1/(r1413727)
>> >> >>
>> >> >> site:
>> >> >> http://people.apache.org/~sebb/net-3.2-RC1/
>> >> >>
>> >> >> The Javadocs (1.4.1) link does not work, nor does the download link.
>> >> >> These will be OK once the site is deployed.
>> >> >>
>> >> >> Source and binary archives (tar.gz and .zip) and Maven jars:
>> >> >>
>> >>
>> https://repository.apache.org/content/repositories/orgapachecommons-078/
>> >> >>
>> >> >> [The tar.gz and .zip files will be moved to dist/commons/net before
>> >> >> promoting the Maven jars to release status]
>> >> >>
>> >> >> Vote will remain open for at least 72 hours.
>> >> >>
>> >> >> -
>> >> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >> >> For additional commands, e-mail: dev-h...@commons.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> >> > JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>> >> > Spring Batch in Action: http://bit.ly/bqpbCK
>> >> > Blog: http://garygregory.wordpress.com
>> >> > Home: http://garygregory.com/
>> >> > Tweet! http://twitter.com/GaryGregory
>> >>
>> >> -
>> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >> For additional commands, e-mail: dev-h...@commons.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> > JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>> > Spring Batch in Action: http://bit.ly/bqpbCK
>> > Blog: http://garygregory.wordpress.com
>> > Home: http://garygregory.com/
>> > Tweet! http://twitter.com/GaryGregory
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Using reflection to test private methods

[Gilles Sadowski]

On Sat, Dec 01, 2012 at 09:39:04PM +, sebb wrote:
> On 30 November 2012 11:43, Luc Maisonobe  wrote:
> > 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. The new implementation of Beta.logBeta(double, double)
> >>> I'm currently working on relies on several private methods through a 
> >>> rather
> >>> complex branching.
> >>> Due to this complicated branching, I find it much safer to have direct
> >>> tests for these private methods, instead of relying on the tests of
> >>> Beta.logBeta to validate these methods.
> >>> Therefore, in order to preserve encapsulation (these private methods 
> >>> should
> >>> really remain private, and not package private, as I previously did [2]), 
> >>> I
> >>> propose to use reflection in the unit tests to access these private
> >>> methods. I've tested this option locally, it seems to me that it is a
> >>> viable option.
> >>>
> >>> What do you think about this compromise?
> >>>
> >>
> >> imho, this is perfectly valid in such a specific case, and I had to do the
> >> same in other projects occasionally.
> >
> > +1, and I used the same trick already in some projects.
> 
> +1 to using reflection in test cases if necessary.
> [I don't see why that even needs a vote!]
> 
> However, I don't see what the issue is with package-private methods,
> so long as the reason for the removal of the private qualifier is
> documented.
> 
> If 3rd party application code creates classes in o.a.c.m packages,
> then any problems that result are entirely up to them to resolve...

IMHO, that's really not the problem (i.e. I agree its theirs).
I just find it dirty from a desing point-of-view to have visibility scope
guided by how easy it would to test with Junit.
Scope in (useful) code should be guided by internal consistency (leaving any
testing consideration).
After some time, it becomes a soiurce or questioning ("Why is this code
package private?"). [And no, I don't think that it is enough reason to
state that reason (for "Junit" testing) is the documentation.]

Sébastien's case rarely occurs, and his workaround is fine. So is his
willingness to provide exhaustive coverage!


Best,
Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[VOTE][RESULT] Release NET 3.2 based on RC1

[sebb]

The vote is now closed.

Voting was as follows:

+1 Oliver Heger
+1 Gary Gregory
+1 Sebastian Bazley

There were no other votes.

All the above are members of the Commons PMC so the vote passes.

Thanks to those who voted.

On 26 November 2012 18:29, sebb  wrote:
> This is a vote to release Apache Commons NET 3.2 based on RC1.
>
> [ ] +1 release it
> [ ] +0 go ahead I don't care
> [ ] -1 no, do not release it because...
>
> tag:
> https://svn.apache.org/repos/asf/commons/proper/net/tags/NET_3_2_RC1/ 
> (r1413727)
>
> site:
> http://people.apache.org/~sebb/net-3.2-RC1/
>
> The Javadocs (1.4.1) link does not work, nor does the download link.
> These will be OK once the site is deployed.
>
> Source and binary archives (tar.gz and .zip) and Maven jars:
> https://repository.apache.org/content/repositories/orgapachecommons-078/
>
> [The tar.gz and .zip files will be moved to dist/commons/net before
> promoting the Maven jars to release status]
>
> Vote will remain open for at least 72 hours.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] Old to new API ("MultivariateDifferentiable(Vector)Function")

[Gilles Sadowski]

Hi Luc.

> 
> I would propose to simply revert my changes on the optimization package 
> and prepare for a reorganization for 4.0. I understand I focused only on
> the type of problems Gilles and myself routinely use, i .e. small size 
> problems 
> where the cost of the evaluation is several orders of magnitude larger than 
> the
> data copying. I forgot the dual case with  very large data sets. I apologize 
> for that.

In the context of an FLOSS project, I don't think that you should apologize
for that. We all do our best (and sometimes beyond) and the lack of full
problem coverage should certainly not rest on the usual suspects (eh,
contributors, I mean. ;-)

> 
> When 3.1 will be out, we will have to solve this so both  cases are handled 
> efficiently, 
> and this would probably be implemented in 4.0.
> 
> Does this seems reasonable? 

At this point, no!

I really want to understand what is wrong, and improve the API on all
accounts (the issues you had, the one I raised, and the feedback from
Konstantin, plus advice from others if possible).

As a user of this package with some deadlines, I don't want to be stuck in
the middle of the road, whereas just a little effort seems required to clear
this up.


Thanks,
Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] Old to new API ("MultivariateDifferentiable(Vector)Function")

[Gilles Sadowski]

On Sat, Dec 01, 2012 at 05:09:00PM -0500, Konstantin Berlin wrote:
> >> 
> >> My opinion is that the package should be organized by what it does rather, 
> >> than how it does it.
> > 
> > My proposal is based on what the user wants to do and on what input is
> > required in order to use the tools in the given package, where all
> > algorithms will share the same interface.
> > 
> 
> I humbly disagree with your claim. The user does not want a vector nor a 
> Jcobian. The user has a problem, and they want to see their options for a 
> solution. That is why they will go into, for example, least-squares. They 
> will see that there are different kinds, so they will go into linear, for 
> example. There they will see all their options and what they need to make it 
> work.

There are probably various way to look at a "problem".

For example, I have a leastsquares "problem" but evaluating the derivatives
is expensive (finite differences), so I nevertheless use the classes in
"direct" (no derivatives).

[We had another discussion (raised by someone who detected what could be
assimilated to bugs) about the "Complex" class (cf. MATH-667). But since
nobody actually uses this class (in ways that trigger the issues), there
is no push to implement another "view". Not sure that illustrates a point
somehow... :-)]

> I also have a problem with how you targeting the package to naive people who 
> want to play around with packages. You want the package to be easily 
> accessible to people who require optimizations. I would imagine most users 
> have a good idea what kind of problem that they have are looking for the 
> optimizer that will solve their problem. By structuring the packages in the 
> way I describe, they first go through the general problem that they have, and 
> then go down into more specific detail with every level. That seems to me the 
> most natural.

I just gave an counter-example (i.e. this is not me as a user whom you
described).


Regards,
Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] Old to new API ("MultivariateDifferentiable(Vector)Function")

[Konstantin Berlin]

> There are probably various way to look at a "problem".
> 
> For example, I have a leastsquares "problem" but evaluating the derivatives
> is expensive (finite differences), so I nevertheless use the classes in
> "direct" (no derivatives).
> 
> [We had another discussion (raised by someone who detected what could be
> assimilated to bugs) about the "Complex" class (cf. MATH-667). But since
> nobody actually uses this class (in ways that trigger the issues), there
> is no push to implement another "view". Not sure that illustrates a point
> somehow... :-)]
> 

I am sorry, but being somewhat familiar with the topic the view you presented 
seems incorrect and opposite to how people in the field use optimizers. The 
reason why you have newton based methods is because quadratic approximation 
pretty much beats any other approach to minimization. The convergence rate is 
significantly faster than direct methods, so it more than makes up for the fact 
that you have to compute derivatives. The only time you should switch to a 
direct method is if your energy landscape is rough and bumpy (like in a 
simulation).

I refer you to slide 20 and beyond, with the link below:

http://www.cs.umd.edu/users/oleary/a607/607unc2hand.pdf
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Using reflection to test private methods

[Ted Dunning]

Google has a nice @ExposedForTesting annotation that they use for this.

There are numerous instances in guava where otherwise private methods are
exposed to the test suite for testing.  It makes a lot of sense, and there
are no questions to anybody looking at the code about what is happening.
 If you really want to do so, you can even implement a code walker that
guarantees that all methods are annotated with the access level and level
of stability.

On Sat, Dec 1, 2012 at 2:25 PM, Gilles Sadowski <
gil...@harfang.homelinux.org> wrote:

> After some time, it becomes a soiurce or questioning ("Why is this code
> package private?"). [And no, I don't think that it is enough reason to
> state that reason (for "Junit" testing) is the doc
>

[GUMP@vmgump]: Project commons-dbcp (in module commons-dbcp-1.x) failed

[Gump]

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 affects 18 projects,
 and has been outstanding for 49 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-dbcp :  Object Pooling
- db-ddlutils :  Easy-to-use component for working with Database Definition 
(...
- jakarta-tomcat-4.0 :  Servlet 2.3 and JSP 1.2 Reference Implementation
- jakarta-tomcat-catalina :  Servlet 2.4 Reference Implementation
- jakarta-tomcat-dbcp :  Servlet 2.4 and JSP 2.0 Reference Implementation
- jakarta-tomcat-jk :  Connectors to various web servers
- javax.el :  Java Servlet 2.5 & Server Pages JSP 2.1 implementation (for 
...
- javax.servlet :  Java Servlet 2.5 & Server Pages JSP 2.1 implementation 
(for ...
- javax.servlet.jsp :  Java Servlet 2.5 & Server Pages JSP 2.1 
implementation (for ...
- solr :  Java Based Search Engine
- solr-test :  Java Based Search Engine
- tomcat-tc6 :  Java Servlet 2.5 & Server Pages JSP 2.1 implementation (for 
...
- tomcat-tc7.0.x :  Tomcat 7.x, a web server implementing Java Servlet 3.0,
...
- tomcat-tc7.0.x-dbcp :  Tomcat 7.x, a web server implementing Java Servlet 
3.0,
...
- tomcat-tc7.0.x-test :  Tomcat 7.x, a web server implementing Java Servlet 
3.0,
...
- tomcat-trunk :  Tomcat 8.x, a web server implementing Java Servlet 3.1,
...
- tomcat-trunk-dbcp :  Tomcat 8.x, a web server implementing Java Servlet 
3.1,
...
- tomcat-trunk-test :  Tomcat 8.x, a web server implementing Java Servlet 
3.1,
...


Full details are available at:

http://vmgump.apache.org/gump/public/commons-dbcp-1.x/commons-dbcp/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-dbcp.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/commons-dbcp-1.x/commons-dbcp/gump_work/build_commons-dbcp-1.x_commons-dbcp.html
Work Name: build_commons-dbcp-1.x_commons-dbcp (Type: Build)
Work ended in a state of : Failed
Elapsed: 9 secs
Command Line: /usr/lib/jvm/java-7-oracle/bin/java -Djava.awt.headless=true 
-Dbuild.sysclasspath=only 
-Xbootclasspath/p:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml 
dist 
[Working Directory: /srv/gump/public/workspace/commons-dbcp-1.x]
CLASSPATH: 
/usr/lib/jvm/java-7-oracle/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/junit/dist/junit-02122012.jar:/srv/gump/public/workspace/junit/dist/junit-dep-02122012.jar:/srv/gump/packages/jta-spec1_0_1/jta-spec1_0_1.jar:/srv/gump/public/workspace/commons-pool-1.x/dist/commons-pool-1.6.1-SNAPSHOT.jar
-
[javac]^
[javac]   where T is a type-variable:
[javac] T extends Object declared in method 
getObject(String,Class)
[javac] 
/srv/gump/public/workspace/commons-dbcp-1.x/src/java/org/apache/commons/dbcp/DelegatingConnection.java:65:
 error: DelegatingConnection is not abstract and does not override abstract 
method getNetworkTimeout() in Connection
[javac] public class DelegatingConnection extends AbandonedTrace
[javac]^
[javac] 
/srv/gump/public/workspace/commons-dbcp-1.x/src/java/org/apache/commons/dbcp/DelegatingDatabaseMetaData.java:38:
 error: DelegatingDatabaseMetaData is not abstract and does not override 
abstract method generatedKeyAlwaysReturned() in DatabaseMetaData
[javac] public class DelegatingDatabaseMetaData extends AbandonedTrace
[javac]^
[javac] 
/srv/gump/public/workspace/commons-dbcp-1.x/src/java/org/apache/commons/dbcp/DelegatingResultSet.java:61:
 error: DelegatingResultSet is not abstract and does not override abstract 
method getObject(String,Class) in ResultSet
[javac] public class DelegatingResultSet extends Aban

[GUMP@vmgump]: Project commons-dbcp2 (in module apache-commons) failed

[Gump]

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 affects 1 projects,
 and has been outstanding for 218 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-dbcp2 :  Database Connection Pool


Full details are available at:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbcp2/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-dbcp2-*[0-9T].jar] identifier set to project 
name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbcp2/gump_work/build_apache-commons_commons-dbcp2.html
Work Name: build_apache-commons_commons-dbcp2 (Type: Build)
Work ended in a state of : Failed
Elapsed: 8 secs
Command Line: /usr/lib/jvm/java-7-oracle/bin/java -Djava.awt.headless=true 
-Dbuild.sysclasspath=only 
-Xbootclasspath/p:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml 
dist 
[Working Directory: /srv/gump/public/workspace/apache-commons/dbcp]
CLASSPATH: 
/usr/lib/jvm/java-7-oracle/lib/tools.jar:/srv/gump/public/workspace/apache-commons/dbcp/dist/classes:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/packages/jta-spec1_0_1/jta-spec1_0_1.jar:/srv/gump/packages/jdbc2_0/jdbc2_0-stdext.jar:/srv/gump/public/workspace/junit/dist/junit-02122012.jar:/srv/gump/public/workspace/junit/dist/junit-dep-02122012.jar:/srv/gump/public/workspace/apache-commons/pool/dist/commons-pool2-2.0-SNAPSHOT.jar
-
[mkdir] Created dir: 
/srv/gump/public/workspace/apache-commons/dbcp/build/classes
[javac] Compiling 52 source files to 
/srv/gump/public/workspace/apache-commons/dbcp/build/classes
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/BasicDataSource.java:52:
 error: BasicDataSource is not abstract and does not override abstract method 
getParentLogger() in CommonDataSource
[javac] public class BasicDataSource implements DataSource {
[javac]^
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingConnection.java:65:
 error: DelegatingConnection is not abstract and does not override abstract 
method getNetworkTimeout() in Connection
[javac] public class DelegatingConnection extends AbandonedTrace
[javac]^
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingStatement.java:46:
 error: DelegatingStatement is not abstract and does not override abstract 
method isCloseOnCompletion() in Statement
[javac] public class DelegatingStatement extends AbandonedTrace implements 
Statement {
[javac]^
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingPreparedStatement.java:57:
 error: DelegatingPreparedStatement is not abstract and does not override 
abstract method isCloseOnCompletion() in Statement
[javac] public class DelegatingPreparedStatement extends DelegatingStatement
[javac]^
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingCallableStatement.java:58:
 error: DelegatingCallableStatement is not abstract and does not override 
abstract method getObject(String,Class) in CallableStatement
[javac] public class DelegatingCallableStatement extends 
DelegatingPreparedStatement
[javac]^
[javac]   where T is a type-variable:
[javac] T extends Object declared in method 
getObject(String,Class)
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingDatabaseMetaData.java:36:
 error: DelegatingDatabaseMetaData is not abstract and does not override 
abstract method generatedKeyAlwaysReturned() in DatabaseMetaData
[javac] public clas

[GUMP@vmgump]: Project commons-digester3 (in module apache-commons) failed

[Gump]

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 issue affects 2 projects,
 and has been outstanding for 49 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-digester3 :  XML to Java Object Configuration
- commons-digester3-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-digester3-*[0-9T].jar] identifier set to 
project name
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/srv/gump/public/workspace/apache-commons/digester/pom.xml
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/gump_work/build_apache-commons_commons-digester3.html
Work Name: build_apache-commons_commons-digester3 (Type: Build)
Work ended in a state of : Failed
Elapsed: 59 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -DskipTests=true --settings 
/srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml 
package 
[Working Directory: /srv/gump/public/workspace/apache-commons/digester]
M2_HOME: /opt/maven2
-
[INFO] [remote-resources:process {execution: default}]
[INFO] [buildnumber:create {execution: default}]
[INFO] Checking for local modifications: skipped.
[INFO] Updating project files from SCM: skipped.
[INFO] Executing: /bin/sh -c cd 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor && svn 
--non-interactive info
[INFO] Working directory: 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor
[INFO] Storing buildNumber: ?? at timestamp: 1354420297245
[INFO] Executing: /bin/sh -c cd 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor && svn 
--non-interactive info
[INFO] Working directory: 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor
[INFO] Storing buildScmBranch: UNKNOWN_BRANCH
[debug] execute contextualize
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] Copying 2 resources to META-INF
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 5 source files to 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor/target/classes
[INFO] [bundle:manifest {execution: bundle-manifest}]
[debug] execute contextualize
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor/src/test/resources
[INFO] Copying 0 resource to META-INF
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Compiling 3 source files to 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor/target/test-classes
>@org.apache.commons.digester3.annotations.rules.ObjectCreate(pattern="rss/channel")
>@org.apache.commons.digester3.annotations.rules.ObjectCreate(pattern="rss/channel/image")
>@org.apache.commons.digester3.annotations.rules.ObjectCreate(pattern="rss/channel/item")
>
[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] error: Impossible to generate class 
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule: 
Attempt to recreate a file for type 
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
[ERROR] error: Impossible to generate class 
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule: 
Attempt to recreate a file for type 
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
[INFO] 2 errors 
[INFO] -
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure

error: Impossible to generate class 
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule: 
Attempt to recreate a file for type 
org.apache.commons.digester3.annota

[GUMP@vmgump]: Project commons-chain2 (in module apache-commons) failed

[Gump]

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 issue affects 1 projects,
 and has been outstanding for 240 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-chain2 :  GoF "Chain of Responsibility" pattern


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-chain2-*[0-9T].jar] identifier set to project 
name
 -DEBUG- Sole pom output [pom.xml] identifier set to project name
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/chain/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/chain/pom.xml
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/gump_work/build_apache-commons_commons-chain2.html
Work Name: build_apache-commons_commons-chain2 (Type: Build)
Work ended in a state of : Failed
Elapsed: 1 min 2 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/chain/gump_mvn_settings.xml package 
[Working Directory: /srv/gump/public/workspace/apache-commons/chain]
M2_HOME: /opt/maven2
-
[INFO] Building war: 
/srv/gump/public/workspace/apache-commons/chain/apps/cookbook-examples/target/chain-cookbook-examples-2.0-SNAPSHOT.war
[INFO] 
[INFO] Building Apache Commons Chain :: Distribution Packages
[INFO]task-segment: [package]
[INFO] 
[INFO] snapshot org.apache.commons:commons-chain2-configuration:2.0-SNAPSHOT: 
checking for updates from apache.snapshots
Downloading: 
http://localhost:8192/repo/m2-snapshot-repository/org/apache/commons/commons-chain2-configuration/2.0-SNAPSHOT/commons-chain2-configuration-2.0-SNAPSHOT.pom
[INFO] Unable to find resource 
'org.apache.commons:commons-chain2-configuration:pom:2.0-SNAPSHOT' in 
repository apache.snapshots (http://repository.apache.org/snapshots)
Downloading: 
http://localhost:8192/repo/m2-snapshot-repository/org/apache/commons/commons-chain2-configuration/2.0-SNAPSHOT/commons-chain2-configuration-2.0-SNAPSHOT.jar
[INFO] Unable to find resource 
'org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT' in 
repository apache.snapshots (http://repository.apache.org/snapshots)
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Failed to resolve artifact.

Missing:
--
1) org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT

  Try downloading the file manually from the project website.

  Then, install it using the command: 
  mvn install:install-file -DgroupId=org.apache.commons 
-DartifactId=commons-chain2-configuration -Dversion=2.0-SNAPSHOT 
-Dpackaging=jar -Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file there: 
  mvn deploy:deploy-file -DgroupId=org.apache.commons 
-DartifactId=commons-chain2-configuration -Dversion=2.0-SNAPSHOT 
-Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency: 
1) org.apache.commons:commons-chain2:pom:2.0-SNAPSHOT
2) org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT

--
1 required artifact is missing.

for artifact: 
  org.apache.commons:commons-chain2:pom:2.0-SNAPSHOT

from the specified remote repositories:
  gump-central (http://localhost:8192/maven2),
  gump-apache.snapshots (http://localhost:8192/repo/m2-snapshot-repository)



[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 1 minute 
[INFO] Finished at: Sun Dec 02 05:01:48 UTC 2012
[INFO] Final Memory: 114M/241M
[INFO] 
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/rss.xml
- Atom: 
http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/

[GUMP@vmgump]: Project commons-proxy-test (in module apache-commons) failed

[Gump]

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 issue affects 1 projects,
 and has been outstanding for 54 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-proxy-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -WARNING- Overriding Maven settings: 
[/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/proxy/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/gump_work/build_apache-commons_commons-proxy-test.html
Work Name: build_apache-commons_commons-proxy-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 15 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/proxy]
M2_HOME: /opt/maven2
-
Running org.apache.commons.proxy.factory.util.TestMethodSignature
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec

Results :

Tests in error: 
  
testMethodInvocationImplementation(org.apache.commons.proxy.interceptor.TestMethodInterceptorAdapter)
  
testSerialization(org.apache.commons.proxy.interceptor.TestMethodInterceptorAdapter)
  
testMethodInterception(org.apache.commons.proxy.interceptor.TestMethodInterceptorAdapter)
  testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker)
  
testMethodInvocation(org.apache.commons.proxy.invoker.TestInvocationHandlerAdapter)
  
testInterceptorEquals(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerEquals(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptorWithSuperclass(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerWithSuperclass(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testProxiesWithClashingFinalMethodInSuperclass(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerHashCode(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testBooleanInterceptorParameter(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testChangingArguments(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testCreateInterceptorProxy(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptingProxyClassCaching(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptingProxySerializable(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptorProxyWithCheckedException(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptorProxyWithUncheckedException(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerProxy(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerProxyClassCaching(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerProxySerializable(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testMethodInvocationClassCaching(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testMethodInvocationDuplicateMethods(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testMethodInvocationImplementation(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testWithNonAccessibleTargetType(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptorHashCode(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  testCreateNullObject(org.apache.commons.proxy.TestProxyUtils)
  testCreateNullObjectWithClassLoader(org.apache.commons.proxy.TestProxyUtils)

Tests run: 179, Failures: 0, Errors: 28, Skipped: 0

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] There 

[GUMP@vmgump]: Project commons-dbutils (in module apache-commons) failed

[Gump]

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 issue affects 1 projects,
 and has been outstanding for 218 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-dbutils :  Commons DbUtils


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-dbutils/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-dbutils-*[0-9T].jar] identifier set to 
project name
 -INFO- Optional dependency mockito failed with reason build failed
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/dbutils/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/dbutils/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/dbutils/target/surefire-reports
 -WARNING- No directory 
[/srv/gump/public/workspace/apache-commons/dbutils/target/surefire-reports]
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbutils/gump_work/build_apache-commons_commons-dbutils.html
Work Name: build_apache-commons_commons-dbutils (Type: Build)
Work ended in a state of : Failed
Elapsed: 17 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/dbutils/gump_mvn_settings.xml package 
[Working Directory: /srv/gump/public/workspace/apache-commons/dbutils]
M2_HOME: /opt/maven2
-
1K downloaded  (mockito-core-1.9.0.pom)
Downloading: 
http://localhost:8192/maven2/org/hamcrest/hamcrest-all/1.1/hamcrest-all-1.1.pom
479b downloaded  (hamcrest-all-1.1.pom)
Downloading: 
http://localhost:8192/maven2/org/mockito/mockito-core/1.9.0/mockito-core-1.9.0.jar
Downloading: 
http://localhost:8192/maven2/org/hamcrest/hamcrest-all/1.1/hamcrest-all-1.1.jar
273K downloaded  (hamcrest-all-1.1.jar)
1381K downloaded  (mockito-core-1.9.0.jar)
[INFO] [antrun:run {execution: javadoc.resources}]
[INFO] Executing tasks

main:
 [copy] Copying 2 files to 
/srv/gump/public/workspace/apache-commons/dbutils/target/apidocs/META-INF
[INFO] Executed tasks
[WARNING] The parameter expression: 'project.build.resources' used in mojo: 
'process' has been deprecated. Use 'project.resources' instead.
[INFO] [remote-resources:process {execution: default}]
[INFO] [buildnumber:create {execution: default}]
[INFO] Checking for local modifications: skipped.
[INFO] Updating project files from SCM: skipped.
[INFO] Executing: /bin/sh -c cd 
/srv/gump/public/workspace/apache-commons/dbutils && svn --non-interactive info
[INFO] Working directory: /srv/gump/public/workspace/apache-commons/dbutils
[INFO] Storing buildNumber: ?? at timestamp: 1354425639947
[INFO] Executing: /bin/sh -c cd 
/srv/gump/public/workspace/apache-commons/dbutils && svn --non-interactive info
[INFO] Working directory: /srv/gump/public/workspace/apache-commons/dbutils
[INFO] Storing buildScmBranch: UNKNOWN_BRANCH
[debug] execute contextualize
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
/srv/gump/public/workspace/apache-commons/dbutils/src/main/resources
[INFO] Copying 2 resources to META-INF
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 29 source files to 
/srv/gump/public/workspace/apache-commons/dbutils/target/classes
[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] 
/srv/gump/public/workspace/apache-commons/dbutils/src/main/java/org/apache/commons/dbutils/DbUtils.java:[334,25]
 error: DriverProxy is not abstract and does not override abstract method 
getParentLogger() in Driver
[INFO] 1 error
[INFO] -
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure
/srv/gump/public/workspace/apache-commons/dbutils/src/main/java/org/apache/commons/dbutils/DbUtils.java:[334,25]
 error: DriverProxy is not abstract and does not override abstract method 
getParentLogger() in Driver

[INFO] 
[INFO] For more information, run Mav

[GUMP@vmgump]: Project commons-scxml-test (in module apache-commons) failed

[Gump]

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 issue affects 1 projects,
 and has been outstanding for 223 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-scxml-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -WARNING- Overriding Maven settings: 
[/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/scxml/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/scxml/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/gump_work/build_apache-commons_commons-scxml-test.html
Work Name: build_apache-commons_commons-scxml-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 24 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -Dsimplelog.defaultlog=info 
--settings 
/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/scxml]
M2_HOME: /opt/maven2
-
[INFO] SimpleSCXMLListener - /s2/s2.1/e1.2
[INFO] SimpleSCXMLListener - /s2/s2.1/e1.2
[INFO] SimpleSCXMLListener - /s2/s2.1
[INFO] SimpleSCXMLListener - /s2
[INFO] SimpleSCXMLListener - transition (event = s2.1.done, cond = null, from = 
/s2, to = /s3)
[INFO] SimpleSCXMLListener - /s3
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.384 sec
Running org.apache.commons.scxml.issues.Issue64Test
[INFO] SCXMLSemantics - null: Begin transition bug test ...
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SCXMLSemantics - null: somedata
[INFO] SCXMLSemantics - null: *somedata
[INFO] SimpleSCXMLListener - transition (event = show.bug, cond = null, from = 
/tranbug, to = /end)
[INFO] SimpleSCXMLListener - /end
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:30:21
 and digester match "scxml/datamodel/misplaced"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:36:19
 and digester match "scxml/state/onentry/foo"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://my.foo.example/"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:37:22
 and digester match "scxml/state/onentry/bar"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:41:21
 and digester match "scxml/state/transition/datamodel"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:42:41
 and digester match "scxml/state/transition/datamodel/data"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://my.foo.example/"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:49:14
 and digester match "scxml/baz"
[INFO] SCXMLSemantics - null: Begin transition bug test ...
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SCXMLSemantics - null: null
[WARN] SimpleErrorReporter - EXPRESSION_ERROR (eval(''*' + dummy'):null): 
[INFO] SimpleSCXMLListener - transition (event = show.bug, cond = null, from = 
/tranbug, to = /end)
[INFO] SimpleSCXMLListener - /end
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.126 sec

Results :

Failed tests: 
  testCustomActionCallbacks(org.apache.commons.scxml.model.CustomActionTest)

Tests run: 229, Failures: 1, Errors: 0, Skipped: 0

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO